unfrozen repo somewhere?

[Patrice Dumas]

Hello,

I understand why rawhide should be frozen at some points, but sometime
there is a package one really wants, that is built in koji, but not
available in rawhide because it is frozen. In my case, for example,
rpm-build is broken but aleady fixed. So maybe it would be worth having
a special repo that would not be enabled, but that would allow to have
the latest builds during a beta freeze. In my opinion this repo should
also be used for Matt rebuilds since there are alot of already fixed FTBS
in his reports due to the freeze, which is a bit annoying.

--
Pat

[Mamoru Tasaka]

Patrice Dumas wrote, at 09/26/2008 06:11 PM +9:00:
>  Hello,
>  
>  I understand why rawhide should be frozen at some points, but sometime
>  there is a package one really wants, that is built in koji, but not
>  available in rawhide because it is frozen. In my case, for example,
>  rpm-build is broken but aleady fixed. So maybe it would be worth having
>  a special repo that would not be enabled, but that would allow to have
>  the latest builds during a beta freeze. In my opinion this repo should
>  also be used for Matt rebuilds since there are alot of already fixed FTBS
>  in his reports due to the freeze, which is a bit annoying.
>  
>  --
>  Pat 
I always use a repo file (named fedora-koji.repo) which contains:
---------------------------------------------------------------
[koji]
name= koji - koji snapshot tree
baseurl=http://koji.fedoraproject.org/static-repos/dist-f10-build-current...
enabled=1
gpgcheck=0
---------------------------------------------------------------

And I think fedora-devel-i386.cfg (in mock) has similar lines.

Mamoru

[David Nielsen]

2008/9/26 Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp&gt;

>  Patrice Dumas wrote, at 09/26/2008 06:11 PM +9:00:
>
> > Hello,
> >
> > I understand why rawhide should be frozen at some points, but sometime
> > there is a package one really wants, that is built in koji, but not
> > available in rawhide because it is frozen. In my case, for example,
> > rpm-build is broken but aleady fixed. So maybe it would be worth having
> > a special repo that would not be enabled, but that would allow to have
> > the latest builds during a beta freeze. In my opinion this repo should
> > also be used for Matt rebuilds since there are alot of already fixed FTBS
> > in his reports due to the freeze, which is a bit annoying.
> >
> > --
> > Pat
> >
>
>  I always use a repo file (named fedora-koji.repo) which contains:
>  ---------------------------------------------------------------
>  [koji]
>  name= koji - koji snapshot tree
>  baseurl=
>  http://koji.fedoraproject.org/static-repos/dist-f10-build-current/$basearch/
>  enabled=1
>  gpgcheck=0
>  ---------------------------------------------------------------
>
>  And I think fedora-devel-i386.cfg (in mock) has similar lines. 

Wow, I never knew koji did that, very cool indeed.

[Ralf Corsepius]

On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  Hello,
>  
>  I understand why rawhide should be frozen at some points, 
Openly said, I don't
understand this. To me, these freezes are a defect
in Rel-Eng's procedures, which could easily be overcome, if they wanted
to.

But, this had been discussed to death, and Rel-Eng made clear, they are
not interested in a change - So be it.

Ralf

[Patrice Dumas]

On Fri, Sep 26, 2008 at 12:35:53PM +0200, Ralf Corsepius wrote:
>  On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  > Hello,
>  > 
>  > I understand why rawhide should be frozen at some points,
>  Openly said, I don't understand this. To me, these freezes are a defect
>  in Rel-Eng's procedures, which could easily be overcome, if they wanted
>  to. 
Indeed, I think that rawhide should not be frozen, only the beta, which
would have specific package changes pushed instead of the reverse.

--
Pat

[Josh Boyer]

On Fri, Sep 26, 2008 at 01:26:43PM +0200, Patrice Dumas wrote:
> On Fri, Sep 26, 2008 at 12:35:53PM +0200, Ralf Corsepius wrote:
> > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
> > > Hello,
> > > 
> > > I understand why rawhide should be frozen at some points,
> > Openly said, I don't understand this. To me, these freezes are a defect
> > in Rel-Eng's procedures, which could easily be overcome, if they wanted
> > to.
>
> Indeed, I think that rawhide should not be frozen, only the beta, which
> would have specific package changes pushed instead of the reverse. 
Alpha was done that way the past two times.  It didn't work out wonderfully.

And by the point you get to Beta, you want all your testing focused on a
single tree.  So having a Beta tree that nobody is testing before Beta release
is pretty pointless.  That is one of the major reasons for freezing rawhide,
so that you get a single tree to test, triage, and focus bug efforts on.

josh

[Patrice Dumas]

On Fri, Sep 26, 2008 at 08:02:25AM -0400, Josh Boyer wrote:
>  
>  And by the point you get to Beta, you want all your testing focused on a
>  single tree.  So having a Beta tree that nobody is testing before Beta release
>  is pretty pointless.  That is one of the major reasons for freezing rawhide,
>  so that you get a single tree to test, triage, and focus bug efforts on. 
I understand that for installs/upgrades using anaconda, thus for images, 
but for users that track rawhide, being able to test if bugs are fixed
without doing a local rebuild is handy. Especially for packages that are
not at the core of the distribution. I guess that maybe it isn't very
practical, but the frozen packages in rawhide could be a subset of the 
packages, including everything in the minimal buildroot, in some groups,
say @base, @base-x, @code, @fedora-packager, @hardware-support,
@input-methods, @legacy-software-development, @legacy-software-support,
@printing, @system-tools, and their dependencies, and the kernel
(and maybe @admin-tools).

--
Pat

[Jesse Keating]

On Fri, 2008-09-26 at 14:31 +0200, Patrice Dumas wrote:
>  I understand that for installs/upgrades using anaconda, thus for
> images, 
>  but for users that track rawhide, being able to test if bugs are fixed
>  without doing a local rebuild is handy. Especially for packages that are
>  not at the core of the distribution. I guess that maybe it isn't very
>  practical, but the frozen packages in rawhide could be a subset of the 
>  packages, including everything in the minimal buildroot, in some groups,
>  say @base, @base-x, @code, @fedora-packager, @hardware-support,
>  @input-methods, @legacy-software-development, @legacy-software-support,
>  @printing, @system-tools, and their dependencies, and the kernel
>  (and maybe @admin-tools). 
Not really practical, bound to be wrong.

Instead we offer static-repos of the continued package flow for those
people who want to bypass any testing of the freeze content.  Those
repos aren't mirrored just yet, and may be in the future, but with our
current resources available, the best way to get things done is to
freeze rawhide.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Bruno Wolff III]

On Fri, Sep 26, 2008 at 09:13:03 -0700,
  Jesse Keating <jkeating(a)redhat.com&gt; wrote:
>  
>  Instead we offer static-repos of the continued package flow for those
>  people who want to bypass any testing of the freeze content.  Those
>  repos aren't mirrored just yet, and may be in the future, but with our
>  current resources available, the best way to get things done is to
>  freeze rawhide. 
This would be nice. When not at a point where I am testing installs, I prefer
to keep following rawhide as it helps testing possible fixes to problems I am
having.

I have something working to get this stuff now, but would prefer to be pulling
from mirrors.

[Jesse Keating]

On Fri, 2008-09-26 at 12:56 -0500, Bruno Wolff III wrote:
>  I have something working to get this stuff now, but would prefer to
> be pulling
>  from mirrors. 
Unfortunately these repos A) change on an hourly basis, depending on
builds done in the tags, and B) are not multilib.  It makes them
somewhat less desirable for mass consumption and mirroring.

What we may eventually do is compose out two rawhide like trees during
freezes.  One that is the freeze content, another that is the unfrozen
content.  The logistics of this haven't been explored too much, mostly
due to lack of resources to realize it.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Bruno Wolff III]

On Fri, Sep 26, 2008 at 10:59:45 -0700,
  Jesse Keating <jkeating(a)redhat.com&gt; wrote:
>  On Fri, 2008-09-26 at 12:56 -0500, Bruno Wolff III wrote:
>  > I have something working to get this stuff now, but would prefer to be pulling
>  > from mirrors.
>  
>  Unfortunately these repos A) change on an hourly basis, depending on
>  builds done in the tags, and B) are not multilib.  It makes them
>  somewhat less desirable for mass consumption and mirroring. 
Even mirrors of the rpms could be useful. My current process involves grabbing
rpms that aren't in the latest rawhide and creating repo information on
my end. I am experimenting with a hack for multilib that doesn't pull
in the same mix as mash does. Currently I am using 'provides' information.
If I really want everything that is i386 specific I need to look at the
files, but that would be slower and I haven't actually needed the missing
stuff yet.

>  What we may eventually do is compose out two rawhide like trees
> during
>  freezes.  One that is the freeze content, another that is the unfrozen
>  content.  The logistics of this haven't been explored too much, mostly
>  due to lack of resources to realize it. 
This sounds like a good idea if you get the people time and mirrors are
OK with carrying it.

It also hurt that this time around the beta freeze was especially long.

[Josh Boyer]

On Fri, Sep 26, 2008 at 02:31:06PM +0200, Patrice Dumas wrote:
> On Fri, Sep 26, 2008 at 08:02:25AM -0400, Josh Boyer wrote:
> > 
> > And by the point you get to Beta, you want all your testing focused on a
> > single tree.  So having a Beta tree that nobody is testing before Beta release
> > is pretty pointless.  That is one of the major reasons for freezing rawhide,
> > so that you get a single tree to test, triage, and focus bug efforts on.
>
> I understand that for installs/upgrades using anaconda, thus for images, 
> but for users that track rawhide, being able to test if bugs are fixed
> without doing a local rebuild is handy. Especially for packages that are
> not at the core of the distribution. I guess that maybe it isn't very
> practical, but the frozen packages in rawhide could be a subset of the 
> packages, including everything in the minimal buildroot, in some groups,
> say @base, @base-x, @code, @fedora-packager, @hardware-support,
> @input-methods, @legacy-software-development, @legacy-software-support,
> @printing, @system-tools, and their dependencies, and the kernel
> (and maybe @admin-tools). 
So now you've sort of separated the packages in Fedora into a "Core" set,
and
then an "Extras" set.  Each set would have different rules around release
time, and probably for updates and such too.

Oh wait... that sounds like Fedora Core and Fedora Extras.

josh

[Patrice Dumas]

On Fri, Sep 26, 2008 at 03:41:32PM -0400, Josh Boyer wrote:
>  
>  So now you've sort of separated the packages in Fedora into a "Core" set,
> and
>  then an "Extras" set.  Each set would have different rules around release
>  time, and probably for updates and such too.
>  
>  Oh wait... that sounds like Fedora Core and Fedora Extras. 
No. The difference between Core and Extras was a different set of people
and responsibilities, and different repos. Moreover in core there was 
many things that are not listed in my list, like clients, desktop apps 
and so on. This is a fundamentaly different distinction. Everything on
my list corresponds, however, with things that were in Core. 

Here I wanted to separate the things that should be stable in freeze
which make the base of the OS, and apps whose changes won't disturb too much
other apps that are on top of those base apps but don't have much
interdependencies (except within bounded groups).

--
Pat

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Fri, Sep 26, 2008 at 03:41:32PM -0400, Josh Boyer wrote: 
>  > So now you've sort of separated the packages in Fedora into
> a "Core"
>  > set, and then an "Extras" set.  Each set would have different rules
>  > around release time, and probably for updates and such too. 
>  > Oh wait... that sounds like Fedora Core and Fedora Extras.
>  No. The difference between Core and Extras was a different set of
> people
>  and responsibilities, and different repos. Moreover in core there was 
>  many things that are not listed in my list, like clients, desktop apps 
>  and so on. This is a fundamentaly different distinction. Everything on
>  my list corresponds, however, with things that were in Core.  
>  Here I wanted to separate the things that should be stable in freeze
>  which make the base of the OS, and apps whose changes won't disturb too
>  much other apps that are on top of those base apps but don't have much
>  interdependencies (except within bounded groups). 
What is "too much disturbance"? Who says that what for you is peripheral
isn't extremely important for the next gal?

There is a saying around here, "Ley pareja no es dura" (Evenhanded law
isn't hard), and (unless there is a /very/ strong reason to make a
difference) I'd prefer handling everything the same way. Cuts down on
endless bickering why something or other isn't in the other set, and what
the rules to belong in each group should be, and flaming over the
(inevitable) mistakes adding a package to the wrong group or handling it
according to the wrong set of rules.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Patrice Dumas]

On Sun, Sep 28, 2008 at 04:32:55PM -0400, Horst H. von Brand wrote:
>  
>  What is "too much disturbance"? Who says that what for you is peripheral
>  isn't extremely important for the next gal? 
My selection is loosely based on what depends on what. At least that's
the idea. It isn't about being important or not. And it is not depending
in the sense of rpm dependencies, but in the sense of needing the 
functionalities provided by the set of packages.

>  There is a saying around here, "Ley pareja no es dura"
> (Evenhanded law
>  isn't hard), and (unless there is a /very/ strong reason to make a
>  difference) I'd prefer handling everything the same way. Cuts down on 
I don't know if it is a strong reason, but it seems to me that there are
packages that need to be frozen because most of the other packages
depend on them, and I propose a heuristic to select them, while it seems
to me that, for other packages, testing fixes is the priority since it
is less likely that other packages depend on them.

Put it otherwise, the frozen set is the set of packages that should be
frozen to be able to test against them, while the other are tested
against the frozen packages. Of course there is no evident way to choose
the set, I propose to use some comps groups, but I perfectly understand
that it may be a bad choice.

--
Pat

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  > Hello, 
>  > I understand why rawhide should be frozen at some points,
>  Openly said, I don't understand this. To me, these freezes are a
> defect
>  in Rel-Eng's procedures, which could easily be overcome, if they wanted
>  to. 
What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora-<next>
gets beaten to a pulp by us rawhideans. Yes, I'd also like for the
rollercoaster ride to continue, but there is no way around that us crazy
bunch needs a little gentle leading to help out stabilize the next
release. Plus I can imagine that most (all?) developers are concentrating
on that job, so there are not many hands free to work of pushing the
envelope forward in any case.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  > > Hello,
>  
>  > > I understand why rawhide should be frozen at some points,
>  
>  > Openly said, I don't understand this. To me, these freezes are a defect
>  > in Rel-Eng's procedures, which could easily be overcome, if they wanted
>  > to.
>  
>  What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora-<next>
>  gets beaten to a pulp by us rawhideans. Yes, I'd also like for the
>  rollercoaster ride to continue, but there is no way around that us crazy
>  bunch needs a little gentle leading to help out stabilize the next
>  release. Plus I can imagine that most (all?) developers are concentrating
>  on that job, so there are not many hands free to work of pushing the
>  envelope forward in any case. 
What I would like to see it Rel-Eng to adopt the development principles,
most other developments apply:

Decouple "product development" (here: FC<N+1>) development from bleeding
edge "unstable/experimental" "head development" (here: rawhide).

To achieve this, most projects first branch a "release branch" and work
on this "release branch" to stabilize it before release/product
deployment. 

I.e. instead of bringing "head development" and "maintenance of released
products on hold" (aka. freezes), I'd recommend Rel-Eng to branch 
FC<N+1>.

Ralf

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  > > > Hello, 
>  > > > I understand why rawhide should be frozen at some
> points, 
>  > > Openly said, I don't understand this. To me, these
> freezes are a defect
>  > > in Rel-Eng's procedures, which could easily be overcome, if they wanted
>  > > to. 
>  > What Rel-Eng wants is that the rawhide snapshot that Is To Be
> Fedora-<next>
>  > gets beaten to a pulp by us rawhideans. Yes, I'd also like for the
>  > rollercoaster ride to continue, but there is no way around that us crazy
>  > bunch needs a little gentle leading to help out stabilize the next
>  > release. Plus I can imagine that most (all?) developers are concentrating
>  > on that job, so there are not many hands free to work of pushing the
>  > envelope forward in any case. 
>  What I would like to see it Rel-Eng to adopt the development
> principles,
>  most other developments apply:
>  
>  Decouple "product development" (here: FC<N+1>) development from bleeding
>  edge "unstable/experimental" "head development" (here: rawhide).
Needs more hands. Starves the "product development" of developers and
testers. Was the idea in Linux before 2.6, was abandoned for exactly the
above reasons.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  > > > > Hello,
>  
>  > > > > I understand why rawhide should be frozen at some points,
>  
>  > > > Openly said, I don't understand this. To me, these freezes are a
> defect
>  > > > in Rel-Eng's procedures, which could easily be overcome, if they
> wanted
>  > > > to.
>  
>  > > What Rel-Eng wants is that the rawhide snapshot that Is To Be
> Fedora-<next>
>  > > gets beaten to a pulp by us rawhideans. Yes, I'd also like for the
>  > > rollercoaster ride to continue, but there is no way around that us crazy
>  > > bunch needs a little gentle leading to help out stabilize the next
>  > > release. Plus I can imagine that most (all?) developers are concentrating
>  > > on that job, so there are not many hands free to work of pushing the
>  > > envelope forward in any case.
>  
>  > What I would like to see it Rel-Eng to adopt the development principles,
>  > most other developments apply:
>  > 
>  > Decouple "product development" (here: FC<N+1>) development from
> bleeding
>  > edge "unstable/experimental" "head development" (here:
> rawhide).
>  
>  Needs more hands. Starves the "product development" of developers and
>  testers. 
I don't see this - To the contrary. I feel the current model is
driving
away developers and testers, esp. packagers.

>   Was the idea in Linux before 2.6, was abandoned for exactly the
>  above reasons. 
... but it is the idea which is being applied almost anywhere else.

Ask yourself: Is the current development model in Fedora a success?

I don't think so.

- Fedora releases essentially are rawhide snapshots. Packages from
rawhide automatically become "stable" (Lack of "rawhide/testing").
E.g.
I have package upgrades pending, I currently don't want to push to
Fedora, because I fear them to be too unstable for a product.

- Fedora's release process starves package development. E.g. I have
several (upstream) package upgrades pending, I can't push to Fedora
because to the freezes are permanently interfering.

- rawhide is too volatile to be usable for many testers, esp. packagers
testing their packages.

- The current process introduces a bloated bureaucracy to work around
the side-effects of "not-branches".

Ralf

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: 
>  > > > > > I understand why rawhide should be frozen at
> some points, 
>  > > > > Openly said, I don't understand this. To me,
> these freezes are a
>  > > > > defect in Rel-Eng's procedures, which could easily be overcome,
>  > > > > if they wanted to. 
>  > > > What Rel-Eng wants is that the rawhide snapshot that
> Is To Be
>  > > > Fedora-<next> gets beaten to a pulp by us rawhideans. Yes, I'd
> also
>  > > > like for the rollercoaster ride to continue, but there is no way
>  > > > around that us crazy bunch needs a little gentle leading to help
>  > > > out stabilize the next release. Plus I can imagine that most (all?) 
>  > > > developers are concentrating on that job, so there are not many
>  > > > hands free to work of pushing the envelope forward in any case. 
>  > > What I would like to see it Rel-Eng to adopt the
> development
>  > > principles, most other developments apply:
>  > > 
>  > > Decouple "product development" (here: FC<N+1>) development
> from
>  > > bleeding edge "unstable/experimental" "head development"
> (here:
>  > > rawhide). 
>  > Needs more hands. Starves the "product development" of
> developers and
>  > testers. 
>  I don't see this - To the contrary. I feel the current model is
> driving
>  away developers and testers, esp. packagers. 
Any hard (or even mushy) data to support this?

>  >  Was the idea in Linux before 2.6, was abandoned for exactly
> the
>  > above reasons. 
>  ... but it is the idea which is being applied almost anywhere else.
Examples?

>  Ask yourself: Is the current development model in Fedora a success?
Need to define what "success" means... if it is keeping a very popular,
solid distribution moving forward, and gathering more packages, I'd have to
say it is.

>  I don't think so. 
How do you define "success" then? Where is Fedora lacking? No, this is not
just making noise, I'm really interested in the answer.

>  - Fedora releases essentially are rawhide snapshots. Packages from
>  rawhide automatically become "stable" (Lack of "rawhide/testing").
> E.g.
>  I have package upgrades pending, I currently don't want to push to
>  Fedora, because I fear them to be too unstable for a product. 
Then they should go to rawhide? Go into your local, testers-only repo? Stay
in koji, and be advertised somewhere?

>  - Fedora's release process starves package development. E.g. I
> have
>  several (upstream) package upgrades pending, I can't push to Fedora
>  because to the freezes are permanently interfering. 
Please elaborate. Freezes are far in between, it would be phenomenal bad
luck if many important upstream just happen to fall into those. And those
can presumably be applied after the freeze is lifted. 

>  - rawhide is too volatile to be usable for many testers, esp.
> packagers
>  testing their packages. 
What packages are we talking about? For rawhide's instability to be of very
much impact, the package development would have to be as fast as rawhide's,
or the package have a lot of tendrils reaching into all nooks and cranies
of the system.

Heck, rawhide is stable enough for me to use as a regular workstation (with
some precautions), how would that be /so/ different than deoing development
work? Besides, building/testing/stabilizing your packages on Fedora current
practically /guarantees/ that by the time the work is finished it is
completely irrelevant, as Fedora has moved on into the blue beyond by then.

>  - The current process introduces a bloated bureaucracy to work
> around
>  the side-effects of "not-branches". 
Please elaborate. I'm sure the people involved would love to get that
workload diminished...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
>  > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
>  
>  > > > > > > I understand why rawhide should be frozen at some points,
>  
>  > > > > > Openly said, I don't understand this. To me, these freezes
> are a
>  > > > > > defect in Rel-Eng's procedures, which could easily be
> overcome,
>  > > > > > if they wanted to.
>  
>  > > > > What Rel-Eng wants is that the rawhide snapshot that Is To Be
>  > > > > Fedora-<next> gets beaten to a pulp by us rawhideans. Yes,
> I'd also
>  > > > > like for the rollercoaster ride to continue, but there is no way
>  > > > > around that us crazy bunch needs a little gentle leading to help
>  > > > > out stabilize the next release. Plus I can imagine that most (all?) 
>  > > > > developers are concentrating on that job, so there are not many
>  > > > > hands free to work of pushing the envelope forward in any case.
>  
>  > > > What I would like to see it Rel-Eng to adopt the development
>  > > > principles, most other developments apply:
>  > > > 
>  > > > Decouple "product development" (here: FC<N+1>) development
> from
>  > > > bleeding edge "unstable/experimental" "head
> development" (here:
>  > > > rawhide).
>  
>  > > Needs more hands. Starves the "product development" of developers
> and
>  > > testers.
>  
>  > I don't see this - To the contrary. I feel the current model is driving
>  > away developers and testers, esp. packagers.
>  
>  Any hard (or even mushy) data to support this? 
I am only speaking for myself here.

>  > >  Was the idea in Linux before 2.6, was abandoned for
> exactly the
>  > > above reasons.
>  
>  > ... but it is the idea which is being applied almost anywhere else.
>  
>  Examples? 
... GNOME, GCC, binutils, gdb.

>  > Ask yourself: Is the current development model in Fedora a
> success?
>  
>  Need to define what "success" means... if it is keeping a very popular,
>  solid distribution moving forward, and gathering more packages, I'd have to
>  say it is.
>  
>  > I don't think so.
>  
>  How do you define "success" then? 
In the sense of "development model assists to achieve a functional and
stable product".

>   Where is Fedora lacking? 
2 fundamental issues:

* Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and
often are unusable. At least to me, most Fedora releases so far only
have reached a point of "acceptable quality" several weeks after
release.

* Support to packagers/ease of use of the infrastructure:
One detail amongst many: The freezes are a major handicap to packagers.

>   No, this is not
>  just making noise, I'm really interested in the answer. 
Neither am wanting to
make noise. I am simply trying to raise attention
to what I consider to be a fundamental problem in Fedora.

>  > - Fedora releases essentially are rawhide snapshots. Packages
> from
>  > rawhide automatically become "stable" (Lack of
> "rawhide/testing"). E.g.
>  > I have package upgrades pending, I currently don't want to push to
>  > Fedora, because I fear them to be too unstable for a product.
>  
>  Then they should go to rawhide? 
If Fedora was using release branches, then this
would be a possibility.

I'd push these packages to rawhide now, and would push them to an FC10
release branch when having gained confidence these upgrades are stable
enough for FC10.

The current development model causes me to withhold these upgrades to
avoid endangering FC10.
=> These upgrades with likely be missing in initial FC10 and may (or may
not) be added to FC10 later (or never).

>   Go into your local, 
That's what they do now => Little
attention, little testing.
=> These upgrades with likely be missing in initial FC10 and may (or may
not) be added to FC10 later (or never).

== Missed opportunities.

>  > - Fedora's release process starves package development. E.g.
> I have
>  > several (upstream) package upgrades pending, I can't push to Fedora
>  > because to the freezes are permanently interfering.
>  
>  Please elaborate. Freezes are far in between, it would be phenomenal bad
>  luck if many important upstream just happen to fall into those. And those
>  can presumably be applied after the freeze is lifted. 
The problem is: Neither a
packager's nor an upstreams' workflow are
necessarily synchronized with Rel-Eng's workflow or Fedora release
cycles (And if they are, things occasionally tend to get worse.)

>  > - rawhide is too volatile to be usable for many testers, esp.
> packagers
>  > testing their packages. 
>  Heck, rawhide is stable enough for me to use as a regular workstation
> (with
>  some precautions), how would that be /so/ different than deoing development
>  work? 
A matter of personal objectives: You probably are working on the
"Fedora
distro". I am working on applications and am using Fedora as a vehicle.

>  > - The current process introduces a bloated bureaucracy to work
> around
>  > the side-effects of "not-branches".
>  
>  Please elaborate. I'm sure the people involved would love to get that
>  workload diminished... 
/me feels a lot of the bureaucracy and other churn Rel-Eng
is imposing
on packagers actually is them playing with symptoms of them not applying
release branches.

Ralf

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
>  > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > > > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote:
[...]

>  > > > > What I would like to see it Rel-Eng to adopt the
> development
>  > > > > principles, most other developments apply:
>  > > > > 
>  > > > > Decouple "product development" (here: FC<N+1>)
> development from
>  > > > > bleeding edge "unstable/experimental" "head
> development" (here:
>  > > > > rawhide). 
>  > > > Needs more hands. Starves the "product
> development" of developers and
>  > > > testers.
>  > 
>  > > I don't see this - To the contrary. I feel the current model is driving
>  > > away developers and testers, esp. packagers. 
>  > Any hard (or even mushy) data to support this? 
>  I am only speaking for myself here. 
I see.

>  > > >  Was the idea in Linux before 2.6, was abandoned for
> exactly the
>  > > > above reasons. 
>  > > ... but it is the idea which is being applied almost
> anywhere else. 
>  > Examples? 
>  ... GNOME, GCC, binutils, gdb. 
>  > > Ask yourself: Is the current development model in Fedora a
> success? 
>  > Need to define what "success" means... if it is
> keeping a very popular,
>  > solid distribution moving forward, and gathering more packages, I'd have to
>  > say it is. 
>  > > I don't think so. 
>  > How do you define "success" then? 
>  In the sense of "development model assists to achieve a
> functional and
>  stable product". 
>  >  Where is Fedora lacking?
>  
>  2 fundamental issues: 
>  * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy
> and
>  often are unusable. At least to me, most Fedora releases so far only
>  have reached a point of "acceptable quality" several weeks after
>  release. 
OK. Need more testers, more shaking out (and fixing!) bugs. Splitting the
user community into "rawhide rollercoaster", "beta testers",
"waiting in
the wings" doesn't help here (beta testers will be a tiny miniority).
The problems lie elsewhere:

- How do we recruit more beta testers? Give them a "I was a beta tester"
  badge of sorts, for example, listing all people who reported a bug in
  beta in a "Thank you for testing Fedora XI" page? Other ideas?
- Make the beta process more effective. Make it last somewhat longer (so
  there is more testing)? Define a set of "standard tests" that any user
  can run on the beta and report back with detailed configuration/setup? 
  Perhaps there should be more in the way of regression tests for each
  package?

>  * Support to packagers/ease of use of the infrastructure:
>  One detail amongst many: The freezes are a major handicap to packagers. 
I just don't see how. One the one hand you complain that rawhide changes
too fast to be a reliable platform on which to develop; on the other hand
you don't want it to slow down ever, not even to shake out last bugs.

[...]

>  > > - Fedora releases essentially are rawhide snapshots.
> Packages from
>  > > rawhide automatically become "stable" (Lack of
> "rawhide/testing"). E.g.
>  > > I have package upgrades pending, I currently don't want to push to
>  > > Fedora, because I fear them to be too unstable for a product. 
>  > Then they should go to rawhide? 
>  If Fedora was using release branches, then this would be a
> possibility. 
Or you could wait a week or so, or (if /really/ urgent) push it upstream.

>  I'd push these packages to rawhide now, and would push them to an
> FC10
>  release branch when having gained confidence these upgrades are stable
>  enough for FC10. 
And next to nobody will test what is in the beta, as we all follow
rawhide. What if the changes turn out bad, and you have to rely on what is
in FC10?

>  The current development model causes me to withhold these upgrades
> to
>  avoid endangering FC10. 
Rightly so.

>  => These upgrades with likely be missing in initial FC10 and may
> (or may
>  not) be added to FC10 later (or never). 
Tough. They will be in FC11 then. It's not that that will take three or
four years...

> >  Go into your local,
> That's what they do now => Little attention, little testing.
>  => These upgrades with likely be missing in initial FC10 and may
> (or may
>  not) be added to FC10 later (or never). 
Why /must/ they be in FC10? It isn't exactly the last of the line...

>  == Missed opportunities.
>  
>  > > - Fedora's release process starves package development. E.g. I have
>  > > several (upstream) package upgrades pending, I can't push to Fedora
>  > > because to the freezes are permanently interfering.
>  > 
>  > Please elaborate. Freezes are far in between, it would be phenomenal bad
>  > luck if many important upstream just happen to fall into those. And those
>  > can presumably be applied after the freeze is lifted. 
>  The problem is: Neither a packager's nor an upstreams'
> workflow are
>  necessarily synchronized with Rel-Eng's workflow or Fedora release
>  cycles (And if they are, things occasionally tend to get worse.) 
So what? There has been whining that Gnome version something wasn't
included, or that GCC missed the deadline, or KDE, or... and that was
smoothed out by including them later (if stable enough) or just in the next
round (if not). Works as designed for me.

>  > > - rawhide is too volatile to be usable for many testers,
> esp. packagers
>  > > testing their packages. 
>  > Heck, rawhide is stable enough for me to use as a regular
> workstation (with
>  > some precautions), how would that be /so/ different than deoing development
>  > work? 
>  A matter of personal objectives: You probably are working on the
> "Fedora
>  distro". I am working on applications and am using Fedora as a vehicle. 
No, Im currently /using/ Fedora as a workstation for day to day use, doing
a bit of development and some testing of bleeding-egde packages. Plus
reporting whenever something blows up, and backtracking.

>  > > - The current process introduces a bloated bureaucracy to
> work around
>  > > the side-effects of "not-branches". 
>  > Please elaborate. I'm sure the people involved would love to
> get that
>  > workload diminished... 
>  /me feels a lot of the bureaucracy and other churn Rel-Eng is
> imposing
>  on packagers actually is them playing with symptoms of them not applying
>  release branches. 
Please explain with apples and oranges /what/ the excessive bureacracy
consists of, and how exactly having to juggle four branches (FC8, FC9, FC10
beta, rawhide) instead of three (FC8, FC9, FC10 beta) helps in reducing
overhead and streamlining the release process.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Nicolas Mailhot]

Le lundi 29 septembre 2008 à 13:59 -0400, Horst H. von Brand a écrit :

>  - Make the beta process more effective. Make it last somewhat longer
> (so
>    there is more testing)? 
Totally useless. The #1 problem in testing is processing bug reports
before they go stale or the reporter gets fed up and starts doing
something else. Increasing the beta window will just make it harder for
testers and developpers to meet themselves on the timeline.

-- 
Nicolas Mailhot

[Les Mikesell]

Nicolas Mailhot wrote:
>  Le lundi 29 septembre 2008 à 13:59 -0400, Horst H. von Brand a écrit
> :
>  
> > - Make the beta process more effective. Make it last somewhat longer (so
> >   there is more testing)?
>  
>  Totally useless. The #1 problem in testing is processing bug reports
>  before they go stale or the reporter gets fed up and starts doing
>  something else. Increasing the beta window will just make it harder for
>  testers and developpers to meet themselves on the timeline. 
You could probably pick up a whole lot more beta testers at a moment's 
notice if you'd roll a VMware image that anyone could download and run 
under most existing OS's.  It wouldn't test all the hardware drivers but 
the apps, filesystems, etc. would all run the same.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Jesse Keating]

On Mon, 2008-09-29 at 14:18 -0500, Les Mikesell wrote:
>  
>  You could probably pick up a whole lot more beta testers at a moment's 
>  notice if you'd roll a VMware image that anyone could download and run 
>  under most existing OS's.  It wouldn't test all the hardware drivers but 
>  the apps, filesystems, etc. would all run the same. 
And why can't you do this with the live images?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Les Mikesell]

Jesse Keating wrote:
>  On Mon, 2008-09-29 at 14:18 -0500, Les Mikesell wrote:
> > You could probably pick up a whole lot more beta testers at a moment's 
> > notice if you'd roll a VMware image that anyone could download and run 
> > under most existing OS's.  It wouldn't test all the hardware drivers but 
> > the apps, filesystems, etc. would all run the same.
>  
>  And why can't you do this with the live images? 
Don't you have (a) burn a CD, and (b) _stop_ running your current 
OS/apps to boot a live image, plus not being able to update them and 
save files conveniently?  All of those are good reasons not to bother. 
And will the live image even run on an Intel Mac?

I suppose you could run a CD live image inside of a bare VMware instance 
but you'd take a double hit or worse on performance plus wasting the 
time and plastic to burn the image.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[James Cassell]

On Mon, 29 Sep 2008 16:56:22 -0400, Les Mikesell <lesmikesell(a)gmail.com&gt;  
wrote:

>  I suppose you could run a CD live image inside of a bare VMware
> instance  
>  but you'd take a double hit or worse on performance plus wasting the  
>  time and plastic to burn the image. 
VMware will let you mount an iso as the boot device, so no plastic-wasting  
needed. (or perhaps, more specifically, let you set the CD-ROM device to  
"Use ISO image")

-- 
James Cassell

[Jesse Keating]

On Mon, 2008-09-29 at 15:56 -0500, Les Mikesell wrote:
>  Don't you have (a) burn a CD,  
No.

>  and (b) _stop_ running your current 
>  OS/apps to boot a live image, 
No, you can boot the iso in a virt environment.  It works great and is
damned fast.

>   plus not being able to update them and 
>  save files conveniently? 
Wrong and wrong.  When using a USB key (which you can also do via virt
systems) you can in fact update software, save files/settings.  The
thing you can't do at this point is update the kernel.

>    All of those are good reasons not to bother.  
Not to bother looking at what features it has also, obviously.

>  And will the live image even run on an Intel Mac? 
Yes, not only native, but also through virt technologies, such as
vmware, kvm, xen, qemu on Linux, vmware and parallels on OS X. 

>  
>  I suppose you could run a CD live image inside of a bare VMware instance 
>  but you'd take a double hit or worse on performance plus wasting the 
>  time and plastic to burn the image. 
How is it a double hit, especially if you're booting from the iso image
rather than a burned media?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Les Mikesell]

Jesse Keating wrote:
>  
>  Wrong and wrong.  When using a USB key (which you can also do via virt
>  systems) you can in fact update software, save files/settings.  The
>  thing you can't do at this point is update the kernel. 
Is the procedure for this documented somewhere?  I didn't think the free 
vmware products would boot a usb image - but haven't tried it either.

> >   All of those are good reasons not to bother. 
>  
>  Not to bother looking at what features it has also, obviously. 
So far I haven't seen anything in release notes that looks anywhere near 
as convenient as downloading a ready to run vmware image.  The process 
to create a bootable USB looks like it requires a already-installed 
system, and I don't see any estimate of the disk space and time it will 
waste to do the 'install to hard drive' in a VM to get a writable 
system.   I've also always had to track down hacks to make vmware tools 
work when I wanted to run fedora under vmware - is that still a problem?

> > I suppose you could run a CD live image inside of a bare VMware
> instance 
> > but you'd take a double hit or worse on performance plus wasting the 
> > time and plastic to burn the image.
>  
>  How is it a double hit, especially if you're booting from the iso image
>  rather than a burned media? 
Isn't there an extra layer of filesystem compression happening to access 
the iso files?  And on a real CD you have the slow seek time too.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Chris Adams]

Once upon a time, Les Mikesell <lesmikesell(a)gmail.com&gt; said:
>  So far I haven't seen anything in release notes that looks
> anywhere near 
>  as convenient as downloading a ready to run vmware image.  The process 
>  to create a bootable USB looks like it requires a already-installed 
>  system, and I don't see any estimate of the disk space and time it will 
>  waste to do the 'install to hard drive' in a VM to get a writable 
>  system.   I've also always had to track down hacks to make vmware tools 
>  work when I wanted to run fedora under vmware - is that still a problem? 
With qemu/qemu-kvm, you can download and run the LiveCD ISO image with
"-cdrom /path/to/image.iso -boot d".  If vmware makes it harder than
that, then I'd say you should give an Open Source virtualization tool a
try.

If you really want to make a disk image to run from, you can set up an
empty disk image file (allow several gig, but the qemu qcow2 image type
only uses more-or-less what you use under the virtual image, so you can
allow 10G or more and let it grow on demand), boot the ISO image, and
transfer to the disk image.  That isn't but a couple of extra steps and
a few minutes of work (since you don't have to wait for CD/DVD seeks).
The only "wasted" space is the ISO image (and if 700M is too much space
for you, you probably don't have enough free space to run the virtual
image anyway).

So:

qemu-img create -f qcow2 liveinst.img 10G
sudo qemu-kvm -m 1024 -hda liveinst.img -cdrom /path/to/livecd.iso -boot d
[click "transfer to disk" and shut down]
rm /path/to/livecd.iso # (if space is at a premium)
sudo qemu-kvm -m 1024 -hda liveinst.img

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Les Mikesell]

Chris Adams wrote:
> > So far I haven't seen anything in release notes that looks anywhere near 
> > as convenient as downloading a ready to run vmware image.  The process 
> > to create a bootable USB looks like it requires a already-installed 
> > system, and I don't see any estimate of the disk space and time it will 
> > waste to do the 'install to hard drive' in a VM to get a writable 
> > system.   I've also always had to track down hacks to make vmware tools 
> > work when I wanted to run fedora under vmware - is that still a problem?
>  
>  With qemu/qemu-kvm, you can download and run the LiveCD ISO image with
>  "-cdrom /path/to/image.iso -boot d".  If vmware makes it harder than
>  that, then I'd say you should give an Open Source virtualization tool a
>  try. 
It's easy enough to boot an iso or iso image file.  But that won't be 
writable.

>  If you really want to make a disk image to run from, you can set up
> an
>  empty disk image file (allow several gig, but the qemu qcow2 image type
>  only uses more-or-less what you use under the virtual image, so you can
>  allow 10G or more and let it grow on demand), boot the ISO image, and
>  transfer to the disk image.  That isn't but a couple of extra steps and
>  a few minutes of work (since you don't have to wait for CD/DVD seeks). 
Doing a couple of extra steps and wasting disk space is one thing for 
something I expect to be able to use.  Doing it frequently to test 
something that probably isn't ready for prime time is something else. My 
point was, and is, that if you'd like more testers it would probably 
help to eliminate those extra steps that each would have to repeat.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Rahul Sundaram]

Les Mikesell wrote:
>  Chris Adams wrote:
> >
> >> So far I haven't seen anything in release notes that looks anywhere 
> >> near as convenient as downloading a ready to run vmware image.  The 
> >> process to create a bootable USB looks like it requires a 
> >> already-installed system, and I don't see any estimate of the disk 
> >> space and time it will waste to do the 'install to hard drive' in a 
> >> VM to get a writable system.   I've also always had to track down 
> >> hacks to make vmware tools work when I wanted to run fedora under 
> >> vmware - is that still a problem?
> >
> > With qemu/qemu-kvm, you can download and run the LiveCD ISO image with
> > "-cdrom /path/to/image.iso -boot d".  If vmware makes it harder than
> > that, then I'd say you should give an Open Source virtualization tool a
> > try.
>  
>  It's easy enough to boot an iso or iso image file.  But that won't be 
>  writable. 
It would be if you make it a Live USB.

http://fedorahosted.org/liveusb-creator

Rahul

[Ralf Corsepius]

On Mon, 2008-09-29 at 13:59 -0400, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote:
>  > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote:
>  > > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote:
>  > > > > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas
> wrote:
>  
>  [...]
>  
>  > > > > > What I would like to see it Rel-Eng to adopt the development
>  > > > > > principles, most other developments apply:
>  > > > > > 
>  > > > > > Decouple "product development" (here: FC<N+1>)
> development from
>  > > > > > bleeding edge "unstable/experimental" "head
> development" (here:
>  > > > > > rawhide).
>  
>  > > > > Needs more hands. Starves the "product development" of
> developers and
>  > > > > testers.
>  > > 
>  > > > I don't see this - To the contrary. I feel the current model is
> driving
>  > > > away developers and testers, esp. packagers.
>  
>  > > Any hard (or even mushy) data to support this? 
>  > >  Where is Fedora lacking?
>  > 
>  > 2 fundamental issues:
>  
>  > * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and
>  > often are unusable. At least to me, most Fedora releases so far only
>  > have reached a point of "acceptable quality" several weeks after
>  > release.
>  
>  OK. Need more testers, more shaking out (and fixing!) bugs.  
My view: Not the too
few testers, but an effect of an unhealthy workflow
and immature infrastructure.

>  Splitting the
>  user community into "rawhide rollercoaster", "beta testers",
> "waiting in
>  the wings" doesn't help here (beta testers will be a tiny miniority).
Correct - These dedicated Fedora testers group can only iron out the
worst "brown paperbag class" bugs and misc. random bug - They will never
can compete with the amount of testing provided by the community. 

>  The problems lie elsewhere:
>  
>  - How do we recruit more beta testers? 
My opinion: By changing the workflow,
encouraging collaboration (e.g.
abandoning ACLs) and by replacing certain people who are known to ignore
bugs.

>   Give them a "I was a beta tester"
>    badge of sorts, for example, listing all people who reported a bug in
>    beta in a "Thank you for testing Fedora XI" page? Other ideas?
>  - Make the beta process more effective. Make it last somewhat longer (so
>    there is more testing)? Define a set of "standard tests" that any user
>    can run on the beta and report back with detailed configuration/setup? 
>    Perhaps there should be more in the way of regression tests for each
>    package?
>  
>  > * Support to packagers/ease of use of the infrastructure:
>  > One detail amongst many: The freezes are a major handicap to packagers.
>  
>  I just don't see how. One the one hand you complain that rawhide changes
>  too fast to be a reliable platform on which to develop; on the other hand
>  you don't want it to slow down ever, not even to shake out last bugs. 
Note:
RAWHIDE vs. PRODUCT 

* Rawhide is TOO unstable to be usable
* Rawhide freezes are stalling the PRODUCT (Here: FC10 is killing FC9).

>  > I'd push these packages to rawhide now, and would push them
> to an FC10
>  > release branch when having gained confidence these upgrades are stable
>  > enough for FC10.
>  
>  And next to nobody will test what is in the beta, as we all follow
>  rawhide. 
The situation would not change at all, because it's essentially the
same
as what currently is happening. The only difference: Freeze would not
not block development.


>  > The current development model causes me to withhold these
> upgrades to
>  > avoid endangering FC10.
>  
>  Rightly so.
>  
>  > => These upgrades with likely be missing in initial FC10 and may (or may
>  > not) be added to FC10 later (or never).
>  
>  Tough. They will be in FC11 then. It's not that that will take three or
>  four years...
>  
>  > >  Go into your local,
>  > That's what they do now => Little attention, little testing.
>  > => These upgrades with likely be missing in initial FC10 and may (or may
>  > not) be added to FC10 later (or never).
>  
>  Why /must/ they be in FC10? It isn't exactly the last of the line... 
Why should
Fedora ship outdated stuff? To a community contributor, the
purpose of Fedora is to serve as medium to distribute packages and to
mutually share packages with other users.

So to answer your question: It's Fedora's job. If Fedora's
infrastructure is too inflexible to handle this, Fedora has failed.


>  > > > - Fedora's release process starves package
> development. E.g. I have
>  > > > several (upstream) package upgrades pending, I can't push to Fedora
>  > > > because to the freezes are permanently interfering.
>  > > 
>  > > Please elaborate. Freezes are far in between, it would be phenomenal bad
>  > > luck if many important upstream just happen to fall into those. And those
>  > > can presumably be applied after the freeze is lifted.
>  
>  > The problem is: Neither a packager's nor an upstreams' workflow are
>  > necessarily synchronized with Rel-Eng's workflow or Fedora release
>  > cycles (And if they are, things occasionally tend to get worse.)
>  
>  So what? There has been whining that Gnome version something wasn't
>  included, or that GCC missed the deadline, or KDE, or... and that was
>  smoothed out by including them later (if stable enough) or just in the next
>  round (if not). Works as designed for me. 
Good for you - Unacceptable to me, as
shame  for Fedora.

>  > > > - The current process introduces a bloated bureaucracy
> to work around
>  > > > the side-effects of "not-branches".
>  
>  > > Please elaborate. I'm sure the people involved would love to get that
>  > > workload diminished...
>  
>  > /me feels a lot of the bureaucracy and other churn Rel-Eng is imposing
>  > on packagers actually is them playing with symptoms of them not applying
>  > release branches.
>  
>  Please explain with apples and oranges /what/ the excessive bureacracy
>  consists of, and how exactly having to juggle four branches (FC8, FC9, FC10
>  beta, rawhide) instead of three (FC8, FC9, FC10 beta) helps in reducing
>  overhead and streamlining the release process. 
Please do yourselves the faviour and
maintain some packages in Fedora. 

Then you'll probably notice the bureaucracy Rel-Eng has implemented and
how immature many things are. 

Ralf

[Tom Lane]

"Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > Decouple "product development" (here: FC<N+1>) development from
> bleeding
> > edge "unstable/experimental" "head development" (here: rawhide).
>  Needs more hands. Starves the "product development" of
> developers and
>  testers. Was the idea in Linux before 2.6, was abandoned for exactly the
>  above reasons. 
Yeah ... when it's time to ship a release, you need a forcing function
to encourage people to test-and-fix-bugs, rather than develop-cool-new-
features.  Branching early encourages people to ignore the release and
do the latter.

The Postgres project has generally avoided early branching, and I think
that policy has been a significant contributor to our ten-year history
of making stable releases.

Branching early works if you have a sufficiently large critical mass of
developers and testers who like to work on stabilizing a release, and
another sufficiently large critical mass of people who prefer to work
on pushing new features forward, plus enough extra manpower to deal with
keeping the two branches in sync.  If you lack any of those things it's
a loser.

There are certainly a small number of open source projects that have
enough popularity and enough ensuing manpower-and-expertise to make a go
of this approach.  To imagine that it's workable for the majority of
projects is to demonstrate lack of connection to reality.  To propose
that it become a distro-wide policy is so ... so ... well, I can't think
of an adjective that's fit to print.

			regards, tom lane

[Ralf Corsepius]

On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
>  "Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  >> Decouple "product development" (here: FC<N+1>) development from
> bleeding
>  >> edge "unstable/experimental" "head development" (here:
> rawhide).
>  
>  > Needs more hands. Starves the "product development" of developers and
>  > testers. Was the idea in Linux before 2.6, was abandoned for exactly the
>  > above reasons.
>  
>  Yeah ... when it's time to ship a release, you need a forcing function
>  to encourage people to test-and-fix-bugs, rather than develop-cool-new-
>  features. 
Correct.

>    Branching early encourages people to ignore the release and
>  do the latter. 
Well, I don't agree. 

IMO, branching encourages "early adopter end-users to try sneak
previews" and to stay away from the "bleeding edge aiming at
developers".

>  The Postgres project has generally avoided early branching, and I
think
>  that policy has been a significant contributor to our ten-year
> history
>  of making stable releases.
>  
>  Branching early works if you have a sufficiently large critical mass of
>  developers and testers who like to work on stabilizing a release, and
>  another sufficiently large critical mass of people who prefer to work
>  on pushing new features forward, plus enough extra manpower to deal with
>  keeping the two branches in sync.  If you lack any of those things it's
>  a loser.
>  
>  There are certainly a small number of open source projects that have
>  enough popularity and enough ensuing manpower-and-expertise to make a go
>  of this approach. 
Small number of projects? Probably a matter of perspective ;)

>    To imagine that it's workable for the majority of
>  projects is to demonstrate lack of connection to reality. 
Pardon, but you probably
can relate, why I have to disagree on this. 

I would turn this argument around: The apparent lack of quality of the
distro, the amount of bureaucracy and ineffectiveness the Fedora
approach cause are a living proof for a non-functional approach.

Ralf

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
>  > "Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:
>  > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote: 
>  > >> Decouple "product development" (here:
> FC<N+1>) development from bleeding
>  > >> edge "unstable/experimental" "head development" (here:
> rawhide). 
>  > > Needs more hands. Starves the "product
> development" of developers and
>  > > testers. Was the idea in Linux before 2.6, was abandoned for exactly the
>  > > above reasons. 
>  > Yeah ... when it's time to ship a release, you need a
> forcing function
>  > to encourage people to test-and-fix-bugs, rather than develop-cool-new-
>  > features. 
>  Correct. 
>  >   Branching early encourages people to ignore the release and
>  > do the latter. 
>  Well, I don't agree. 
>
>  IMO, branching encourages "early adopter end-users to try sneak
>  previews" and to stay away from the "bleeding edge aiming at
>  developers". 
Needs some data to back it up. BTW, data for other classes of development
efforts (smaller scale, less developers, slower progress, ...) don't
necessarily apply (but would be useful).

[...]

>  > There are certainly a small number of open source projects that
> have
>  > enough popularity and enough ensuing manpower-and-expertise to make a go
>  > of this approach. 
>  Small number of projects? Probably a matter of perspective ;) 
You' have to provide data to back up your perspective then.

>  >   To imagine that it's workable for the majority of
>  > projects is to demonstrate lack of connection to reality. 
>  Pardon, but you probably can relate, why I have to disagree on this.
>
>  
>  I would turn this argument around: The apparent lack of quality of the
>  distro, the amount of bureaucracy and ineffectiveness the Fedora
>  approach cause are a living proof for a non-functional approach. 
How do you measure "distro quality", "amount of bureacracy" (and how
much
of that is "too much"), "effectiveness"?

I'd say the fact that we are discussing this shows that the qualility is at
least decent enough for serious consideration. Others I can't really see
what you mean, so I can't comment. In any case, this would need to be
contrasted with other distros for a valid discussion.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
>  > > "Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:
>  > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote: 
>  > >   To imagine that it's workable for the majority of
>  > > projects is to demonstrate lack of connection to reality.
>  
>  > Pardon, but you probably can relate, why I have to disagree on this. 
>  > 
>  > I would turn this argument around: The apparent lack of quality of the
>  > distro, the amount of bureaucracy and ineffectiveness the Fedora
>  > approach cause are a living proof for a non-functional approach.
>  
>  How do you measure "distro quality", 
My subjective measure is
"distro works for me without major effort".

Reality is: This doesn't apply.

>   "amount of bureacracy" (and how much
>  of that is "too much"), "effectiveness"? 
koji, bodhi, packagedb, acls, freezes, bugzilla, trac, wikis, mails to
rel-eng/<committee dejour>, the "incident", the triagers, server
downtimes, mirror latencies, bugs not getting fixed, ...

All together (not worth mentioning all the bugs and nits they suffer
from) have a massive impact on effectiveness. Openly said, it has hardly
ever been less effective to contribute to Fedora as it is in recent
past.

>  I'd say the fact that we are discussing this shows that the
> qualility is at
>  least decent enough for serious consideration. 
Certainly - Otherwise, I wasn't
be using Fedora.

Ralf

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
>  > > > "Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:
>  > > > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  
>  > > >   To imagine that it's workable for the majority of
>  > > > projects is to demonstrate lack of connection to reality. 
>  > > Pardon, but you probably can relate, why I have to disagree
> on this.  
>  > > I would turn this argument around: The apparent lack of
> quality of the
>  > > distro, the amount of bureaucracy and ineffectiveness the Fedora
>  > > approach cause are a living proof for a non-functional approach. 
>  > How do you measure "distro quality", 
>  My subjective measure is "distro works for me without major
> effort". 
Done long ago. Sure, some rough edges do remain always, but it isn't "major
effort" for Fedora (hasn't really been for all of Red Hat then Fedora
history as long back as I remember).

>  Reality is: This doesn't apply. 
>  >  "amount of bureacracy" (and how much
>  > of that is "too much"), "effectiveness"? 
>  koji, bodhi, packagedb, acls, freezes, bugzilla, trac, wikis, 
All tools meant to /decrease/ workload (or make it more productive).

>                                                                mails
> to
>  rel-eng/<committee dejour>, 
Sad fact of life is that once the crowd grows too large, some explicit
coordination has to come in.

>                              the "incident", 
Not Rel-Eng's fault, I'd sincerely hope. Sure, it would have been better to
have procedures in place to handle such in a more streamlined way, but then
again that would either mean the incidents are so frequent that everybody
knows in their sleep how to handle them, or having a think-tank planing out
all possible (and imposible) scenarios and lines of action, resulting in a
lot of extra bureacracy and friction.

>                                              the triagers, 
What is the problem with them? They are supposed to validate that bugs are
for real, so I can't see how they hinder development progress. To the
contrary, they should prevent developer's inboxes clogged with useless bug
reports.

>                                                            server
>  downtimes, 
Always bad, true. How do you propose help here?

>             mirror latencies, 
Not Fedora's fault; more the contrary, as Fedora is popular more mirrors
are needed (and problems with any one get more visible).

>                               bugs not getting fixed, ... 
Developer's fault. How do you want to fix this? Training camp for newbie
developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs
in Fedora 10" listing patch contributors, bug triagers, ...)?

User's fault (Yes, I've been known to vanish from sight and not following
up on my own bug reports when I was too busy elsewhere).

>  All together (not worth mentioning all the bugs and nits they suffer
>  from) have a massive impact on effectiveness. Openly said, it has hardly
>  ever been less effective to contribute to Fedora as it is in recent
>  past. 
Please, /show/ how to make it better. /Tell/ where or how the workflow
could be streamlined. "More branches" just makes for a swampy river delta,
not smoother flow AFAIKS.

>  > I'd say the fact that we are discussing this shows that the
> qualility is at
>  > least decent enough for serious consideration. 
>  Certainly - Otherwise, I wasn't be using Fedora. 
It's certainly not perfect, but good enough for me (and fun to booth!).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Les Mikesell]

Horst H. von Brand wrote:
> >                              bugs not getting fixed, ...
>  
>  Developer's fault. 
It's not the developer's fault that you _ship_ new bugs.

>  How do you want to fix this? Training camp for newbie
>  developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs
>  in Fedora 10" listing patch contributors, bug triagers, ...)? 
Just don't ship them.  If someone has to fix bugs in a released Fedora 
as opposed to rawhide or upstream before the version is packaged, you've 
already lost.

>  Please, /show/ how to make it better. /Tell/ where or how the
> workflow
>  could be streamlined. "More branches" just makes for a swampy river delta,
>  not smoother flow AFAIKS. 
You probably can't match RHEL's QA for free, but testing - and not 
shipping things that don't pass - is the only way things can get better.

> >> I'd say the fact that we are discussing this shows that
> the qualility is at
> >> least decent enough for serious consideration.
>  
> > Certainly - Otherwise, I wasn't be using Fedora.
>  
>  It's certainly not perfect, but good enough for me (and fun to booth!). 
I've heard the term used as in "an instrument's tuning is 'good
enough' 
for folk music" or "an approximation is 'good enough' for government 
work".  What's 'good enough' for an operating system?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Horst H. von Brand wrote:
>  >>                              bugs not getting fixed, ... 
>  > Developer's fault. 
>  It's not the developer's fault that you _ship_ new bugs.
OK, packager's fault in that case then.

>  > How do you want to fix this? Training camp for newbie
>  > developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs
>  > in Fedora 10" listing patch contributors, bug triagers, ...)? 
>  Just don't ship them. 
If you have some sort of bug-detector that I can wave over packages before
letting them loose...

>                        If someone has to fix bugs in a released
> Fedora
>  as opposed to rawhide or upstream before the version is packaged,
>  you've already lost. 
As things stand, I'd bet the very wast majority of people don't get
"upstream" but something packaged by some distribution. If I'm right, the
/only/ place where you can catch bugs is through the distribution...

>  > Please, /show/ how to make it better. /Tell/ where or how the
> workflow
>  > could be streamlined. "More branches" just makes for a swampy river
> delta,
>  > not smoother flow AFAIKS. 
>  You probably can't match RHEL's QA for free, but testing -
> and not
>  shipping things that don't pass - is the only way things can get
>  better. 
Pray tell us, exactly how do we /do/ that? I think we all agree that that
is the ideal, but I strongly believe it is unatainable in pratice.

>  >>> I'd say the fact that we are discussing this shows
> that the qualility
>  >>> is at least decent enough for serious consideration. 
>  >> Certainly - Otherwise, I wasn't be using Fedora.
>  > It's certainly not perfect, but good enough for me (and fun to
>  > booth!). 
>  I've heard the term used as in "an instrument's tuning
> is 'good
>  enough' for folk music" or "an approximation is 'good enough' for
>  government work".  What's 'good enough' for an operating system? 
Works mostly. Doesn't crash too often. Doesn't destroy valuable data except
under extremely unlikely circumstances.

What "mostly", "too often", "extremely unlikely" mean in the
above is up to
the beholder. Yes, and ideal system won't ever do any of the above, but
then the machine could get hit by a meteorite.

Yes, there are systems that provably approach the above ideal, but they are
extremely limited (so much that you'd yearn for the lush MS-DOS environment).

This is engineering, not mathematics. And even in mathematics there have
been mistakes...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Les Mikesell]

Horst H. von Brand wrote:
>  
> > It's not the developer's fault that you _ship_ new bugs.
>  
>  OK, packager's fault in that case then. 
More realistically, the packager not having encountered the bug.

> > Just don't ship them.
>  
>  If you have some sort of bug-detector that I can wave over packages before
>  letting them loose... 
Large numbers of testers are the best way. There's nothing quite like 
the real world.

> > You probably can't match RHEL's QA for free, but testing
> - and not
> > shipping things that don't pass - is the only way things can get
> > better.
>  
>  Pray tell us, exactly how do we /do/ that? I think we all agree that that
>  is the ideal, but I strongly believe it is unatainable in pratice. 
The big problem for me is that it's a package deal.  I wouldn't mind 
beta testing a few apps at a time on my working system with a stable OS 
and libraries, but to run them you also have to take an experimental 
kernel and device drivers.  And my history with those on fedora is that 
I waste too much time getting the hardware to work with new versions. 
Maybe that's changed...   If you had a way to separate the apps from the 
OS, you might find people more willing to test the parts that interested 
them.

> > I've heard the term used as in "an instrument's
> tuning is 'good
> > enough' for folk music" or "an approximation is 'good enough'
> for
> > government work".  What's 'good enough' for an operating system?
>  
>  Works mostly. Doesn't crash too often. Doesn't destroy valuable data except
>  under extremely unlikely circumstances. 
Kernels that don't boot on machines where the last version worked or 
lose the ability to access devices like firewire drives isn't 'mostly' 
enough for me.

>  This is engineering, not mathematics. And even in mathematics there
> have
>  been mistakes... 
But would you want to test a plane where the engineers said it was 
probably good enough and didn't crash too often?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Horst H. von Brand wrote: 
[...]

>  >> You probably can't match RHEL's QA for free, but
> testing - and not
>  >> shipping things that don't pass - is the only way things can get
>  >> better. 
>  > Pray tell us, exactly how do we /do/ that? I think we all agree
> that
>  > that is the ideal, but I strongly believe it is unatainable in pratice. 
>  The big problem for me is that it's a package deal.  I
> wouldn't mind
>  beta testing a few apps at a time on my working system with a stable
>  OS and libraries, but to run them you also have to take an
>  experimental kernel and device drivers.  And my history with those on
>  fedora is that I waste too much time getting the hardware to work with
>  new versions. Maybe that's changed...   If you had a way to separate
>  the apps from the OS, you might find people more willing to test the
>  parts that interested them. 
Many problems are integration problems, i.e., package version foo doesn't
work with library version bar. It also happens that to run the very
latest-and-greatest version of the package you need experimental(ish)
versions of other stuff.

>  >> I've heard the term used as in "an instrument's
> tuning is 'good
>  >> enough' for folk music" or "an approximation is 'good
> enough' for
>  >> government work".  What's 'good enough' for an operating
> system? 
>  > Works mostly. Doesn't crash too often. Doesn't destroy
> valuable data
>  > except under extremely unlikely circumstances. 
>  Kernels that don't boot on machines where the last version worked
Keep the next-to-last one around just in case. Have a LiveCD of the lastest
stable/beta at hand for the case it gets too screwed up. Yes, it's a
nuisance.

>                                                                    or
>  lose the ability to access devices like firewire drives isn't 'mostly'
>  enough for me. 
Ditto.

>  > This is engineering, not mathematics. And even in mathematics
> there have
>  > been mistakes... 
>  But would you want to test a plane where the engineers said it was
>  probably good enough and didn't crash too often? 
So you have never heard of plane crashes? Or other failures? In the end, as
100% perfect is not realistically doable, you have to make do with "good
enough", and what /that/ means depends on the circumstances: The kernel of
a game console (a crash means a minor inconvenience or at most a lost game)
has /very/ different safety/security requirements than software controlling
a radiation therapy aparatus (which could very well be lethal to the
patient).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Jesse Keating]

On Wed, 2008-10-01 at 11:27 -0400, Horst H. von Brand wrote:
>  has /very/ different safety/security requirements than software
> controlling
>  a radiation therapy aparatus (which could very well be lethal to the
>  patient). 
Yet the patient still has to (at least in my country) sign a waiver
stating that they understand the procedure may in fact kill them,
because it's not perfect, it's good enough.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Les Mikesell]

Horst H. von Brand wrote:
>  
> > The big problem for me is that it's a package deal.  I wouldn't mind
> > beta testing a few apps at a time on my working system with a stable
> > OS and libraries, but to run them you also have to take an
> > experimental kernel and device drivers.  And my history with those on
> > fedora is that I waste too much time getting the hardware to work with
> > new versions. Maybe that's changed...   If you had a way to separate
> > the apps from the OS, you might find people more willing to test the
> > parts that interested them.
>  
>  Many problems are integration problems, i.e., package version foo doesn't
>  work with library version bar. It also happens that to run the very
>  latest-and-greatest version of the package you need experimental(ish)
>  versions of other stuff. 
Hence my initial suggestion of a ready-to-run, fully integrated vmware 
image that anyone with a working mac, windows, or linux can fire up 
nondestructively with no install or prep work.

> > Kernels that don't boot on machines where the last version
> worked
>  
>  Keep the next-to-last one around just in case. Have a LiveCD of the lastest
>  stable/beta at hand for the case it gets too screwed up. Yes, it's a
>  nuisance. 
If you want lots of testers, make it not a nuisance, safe, and 
non-destructive.

> > But would you want to test a plane where the engineers said it
> was
> > probably good enough and didn't crash too often?
>  
>  So you have never heard of plane crashes? 
Yes, have you heard of simulators where you can do the preliminary 
testing without danger?  That's what vmware provides.

>  Or other failures? In the end, as
>  100% perfect is not realistically doable, you have to make do with "good
>  enough", and what /that/ means depends on the circumstances: The kernel of
>  a game console (a crash means a minor inconvenience or at most a lost game)
>  has /very/ different safety/security requirements than software controlling
>  a radiation therapy aparatus (which could very well be lethal to the
>  patient). 
The circumstances are that vmware server/player is free, as is a timed 
demo of fusion for the mac.  A crash inside of vmware isn't even a minor 
inconvenience to the host.  And as fast as fedora betas change, it would 
probably take less bandwidth and certainly less user time to keep fully 
updated ready-to-run images available instead of making users download 
isos than need installation and then updates.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Jindrich Novy]

Hi,

On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
>  Hello,
>  
>  I understand why rawhide should be frozen at some points, but sometime
>  there is a package one really wants, that is built in koji, but not
>  available in rawhide because it is frozen. In my case, for example,
>  rpm-build is broken but aleady fixed. So maybe it would be worth having
>  a special repo that would not be enabled, but that would allow to have
>  the latest builds during a beta freeze. In my opinion this repo should
>  also be used for Matt rebuilds since there are alot of already fixed FTBS
>  in his reports due to the freeze, which is a bit annoying.
>   
Just mailed rel-eng guys if it's possible to move the new rpm to beta.

Jindrich

>  --
>  Pat
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list 
-- 
Jindrich Novy <jnovy(a)redhat.com&gt;   http://people.redhat.com/jnovy/

[Josh Boyer]

On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote:
> Hi,
>
> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> > Hello,
> > 
> > I understand why rawhide should be frozen at some points, but sometime
> > there is a package one really wants, that is built in koji, but not
> > available in rawhide because it is frozen. In my case, for example,
> > rpm-build is broken but aleady fixed. So maybe it would be worth having
> > a special repo that would not be enabled, but that would allow to have
> > the latest builds during a beta freeze. In my opinion this repo should
> > also be used for Matt rebuilds since there are alot of already fixed FTBS
> > in his reports due to the freeze, which is a bit annoying.
> > 
>
> Just mailed rel-eng guys if it's possible to move the new rpm to beta. 
What email address did you use?  I don't see it on the rel-eng list, nor on
the trac thing.

josh

[Hans de Goede]

Josh Boyer wrote:
>  On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote:
> > Hi,
> >
> > On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> >> Hello,
> >>
> >> I understand why rawhide should be frozen at some points, but sometime
> >> there is a package one really wants, that is built in koji, but not
> >> available in rawhide because it is frozen. In my case, for example,
> >> rpm-build is broken but aleady fixed. So maybe it would be worth having
> >> a special repo that would not be enabled, but that would allow to have
> >> the latest builds during a beta freeze. In my opinion this repo should
> >> also be used for Matt rebuilds since there are alot of already fixed FTBS
> >> in his reports due to the freeze, which is a bit annoying.
> >>
> > Just mailed rel-eng guys if it's possible to move the new rpm to beta.
>  
>  What email address did you use?  I don't see it on the rel-eng list, nor on
>  the trac thing. 
Thats most likely because rel-eng(a)fedoraproject.org is broken (it was about a 
week ago) which I've already reported  multiple times but with no result sofar.

Regards,

hans

[Josh Boyer]

On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote:
>  Josh Boyer wrote:
> > On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote:
> >> Hi,
> >>
> >> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> >>> Hello,
> >>>
> >>> I understand why rawhide should be frozen at some points, but sometime
> >>> there is a package one really wants, that is built in koji, but not
> >>> available in rawhide because it is frozen. In my case, for example,
> >>> rpm-build is broken but aleady fixed. So maybe it would be worth having
> >>> a special repo that would not be enabled, but that would allow to have
> >>> the latest builds during a beta freeze. In my opinion this repo should
> >>> also be used for Matt rebuilds since there are alot of already fixed FTBS
> >>> in his reports due to the freeze, which is a bit annoying.
> >>>
> >> Just mailed rel-eng guys if it's possible to move the new rpm to beta.
> >
> > What email address did you use?  I don't see it on the rel-eng list, nor on
> > the trac thing.
>
>  Thats most likely because rel-eng(a)fedoraproject.org is broken (it was 
>  about a week ago) which I've already reported  multiple times but with no 
>  result sofar. 
https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004....

josh

[Thorsten Leemhuis]

On 26.09.2008 15:13, Josh Boyer wrote:
>  On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote:
> > Josh Boyer wrote:
> >> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote:
> >>> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> >>>> I understand why rawhide should be frozen at some points, but sometime
> >>>> there is a package one really wants, that is built in koji, but not
> >>>> available in rawhide because it is frozen. In my case, for example,
> >>>> rpm-build is broken but aleady fixed. So maybe it would be worth having
> >>>> a special repo that would not be enabled, but that would allow to have
> >>>> the latest builds during a beta freeze. In my opinion this repo should
> >>>> also be used for Matt rebuilds since there are alot of already fixed
> FTBS
> >>>> in his reports due to the freeze, which is a bit annoying.
> >>> Just mailed rel-eng guys if it's possible to move the new rpm to beta.
> >> What email address did you use?  I don't see it on the rel-eng list, nor on
> >> the trac thing.
> > Thats most likely because rel-eng(a)fedoraproject.org is broken (it was 
> > about a week ago) which I've already reported  multiple times but with no 
> > result sofar.
>  https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.... 
http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy

CU
knurd

[Thorsten Leemhuis]

On 26.09.2008 16:37, Thorsten Leemhuis wrote:
>  On 26.09.2008 15:13, Josh Boyer wrote:
> > On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote:
> >> Josh Boyer wrote:
> >>> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote:
> >>>> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> >>>>> I understand why rawhide should be frozen at some points, but
> sometime
> >>>>> there is a package one really wants, that is built in koji, but not
> >>>>> available in rawhide because it is frozen. In my case, for example,
> >>>>> rpm-build is broken but aleady fixed. So maybe it would be worth
> having
> >>>>> a special repo that would not be enabled, but that would allow to
> have
> >>>>> the latest builds during a beta freeze. In my opinion this repo
> should
> >>>>> also be used for Matt rebuilds since there are alot of already fixed
> FTBS
> >>>>> in his reports due to the freeze, which is a bit annoying.
> >>>> Just mailed rel-eng guys if it's possible to move the new rpm to
> beta.
> >>> What email address did you use?  I don't see it on the rel-eng list, nor
> on
> >>> the trac thing.
> >> Thats most likely because rel-eng(a)fedoraproject.org is broken (it was 
> >> about a week ago) which I've already reported  multiple times but with no 
> >> result sofar.
> > https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004....
>   http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy 
Note: Normally I don't send mails that contain just a link, but it 
seemed the right thing to do here, as the post before that was just a 
link as well. ;-)

What I wanted to say with the link: Do you really expect that everybody 
can think of each and every mail that is a few weeks old? And: we have a 
wiki for a reasons, so why didn't rel-eng simply update the page while 
the problem in question persist? Note that
http://www.google.com/search?q=rel-eng%40fedoraproject.org++site%3Afedora...
finds a few other places that might need updating to prevent further 
confusion. For example:

http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

CU
knurd

[Josh Boyer]

On Fri, Sep 26, 2008 at 04:37:56PM +0200, Thorsten Leemhuis wrote:
> >> Thats most likely because rel-eng(a)fedoraproject.org is broken
> (it was 
> >> about a week ago) which I've already reported  multiple times but 
> >> with no result sofar.
> > https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004....
>
>  http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy 
Touche.

If I could figure out a good way to make this a picture, I would post it to
failblog.org with the caption "Rel-Eng communication fail".

Though I noticed that you didn't fix it while you were there.  So now we have
both Wiki fail (*gasp* out of date wiki pages!! *gasp*) and community fail.

/me goes to fail some more

josh

[Patrice Dumas]

On Fri, Sep 26, 2008 at 11:53:00AM -0400, Josh Boyer wrote:
>  
>  Though I noticed that you didn't fix it while you were there.  So now we have
>  both Wiki fail (*gasp* out of date wiki pages!! *gasp*) and community fail. 
Thorsten already answered, but I think this is a fundamental error to
think that a wiki means that everybody should change everywhere. It is
very important that people restrict themselves to their areas of
expertise. That being said, community members can help with the wiki
ioutside of their area of expertise, but only under the guidance of
somebody who knows.

So I am not sure it is failure here.

--
Pat

[Jesse Keating]

On Fri, 2008-09-26 at 23:32 +0200, Patrice Dumas wrote:
>  Thorsten already answered, but I think this is a fundamental error
> to
>  think that a wiki means that everybody should change everywhere. It is
>  very important that people restrict themselves to their areas of
>  expertise. That being said, community members can help with the wiki
>  ioutside of their area of expertise, but only under the guidance of
>  somebody who knows. 

The "community" (aren't we all community?) doesn't have to edit it.
However if they notice that it's wrong, they could bring it to the
attention of the group who "owns" those pages.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Patrice Dumas]

On Fri, Sep 26, 2008 at 02:55:39PM -0700, Jesse Keating wrote:
>  
>  The "community" (aren't we all community?) doesn't have to edit it.
>  However if they notice that it's wrong, they could bring it to the
>  attention of the group who "owns" those pages. 
Agreed.

--
Pat

[Thorsten Leemhuis]

On 26.09.2008 23:55, Jesse Keating wrote:
>  On Fri, 2008-09-26 at 23:32 +0200, Patrice Dumas wrote:
> > Thorsten already answered, but I think this is a fundamental error to
> > think that a wiki means that everybody should change everywhere. It is
> > very important that people restrict themselves to their areas of
> > expertise. That being said, community members can help with the wiki
> > ioutside of their area of expertise, but only under the guidance of
> > somebody who knows. 
+1

>  The "community" (aren't we all community?) doesn't
> have to edit it.
>  However if they notice that it's wrong, they could bring it to the
>  attention of the group who "owns" those pages. 
Hmmm. After reading this para and the stuff you wrote in
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02494...
(¹) I more and more get the impression you assume I was aware of the 
problem in question (email to rel-eng(a)fedoraproject.org mentioned on 
several wiki pages) for quite a long while already.

That's not the case. I saw the mail from jwb and then just used google 
(search term: "rel-eng(a)fedoraproject.org site:fedoraproject.org") and 
found important pages that were misleading. I then immediately mailed 
the list. Yes, the first mail I send was a bit unobvious (jwb got the 
message :-) ), but that's why I wrote another one as reply to myself 
immediately after sending the first one ;-)

Cu
knurd

(¹) I didn't really understand that mail in this context; I thought it 
was not worth discussing this further as it wouldn't lead to anything 
productive, hence I didn't reply.

And note, of course I agree that making other people or groups aware of 
a problem when you spot one is the best for everyone. Most people should 
know that I do that and/or fix things myself immediately as long as that 
makes sense (didn#t make sense here)

P.S.: I hope this sub-thread can now die... It seems just another proof 
  for the statement "sometimes discussing things on mailing lists simply 
doesn't work"

[Jesse Keating]

On Fri, 2008-09-26 at 16:37 +0200, Thorsten Leemhuis wrote:
>  
>  http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy 
If you knew the page was wrong, why didn't you fix it?  Just so that you
could point out that we forgot to change a wiki page somewhere?  Thanks.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Thorsten Leemhuis]

On 26.09.2008 18:14, Jesse Keating wrote:
>  On Fri, 2008-09-26 at 16:37 +0200, Thorsten Leemhuis wrote:
> > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy
>  If you knew the page was wrong, why didn't you fix it? 
- I'm not in rel-eng, thus

-- I was unsure how to best fix it, as "mail rel-eng@" is used on 
multiple pages in the wiki; creating a dedicated "how to contact 
rel-eng" page seemed and seems like the best to me, but that is more 
than a small change thus someone from rel-eng should do it or ACK it

-- I don't know anything about the issue in question besides what is 
written in the (quite old) mail jwb pointed to. Thus I'm didn't feel 
familiar with the issue enough to do changes as those easily might have 
been wrong or obsolete just a few minutes later in case someone enabls 
the mail-> trac gateway again

- I just had hit the "log-out" button in the time-tracking system at 
work one or two minutes earlier and send the mail right before driving home

>   Just so that you could point out that we forgot to change a 
s/a/multiple/ afaics

>  wiki page somewhere?   
Yes, indeed -- and at the same time it was also a nitpick to the mail 
style jwb used. Jwb got the message and responded in a nice way I really 
liked. The other reply I got was just a reminder for one of the reasons 
why I'm contributing a whole lot less to the Fedora project these days 
then one or two years ago.

CU
knurd

[Jesse Keating]

On Fri, 2008-09-26 at 18:44 +0200, Thorsten Leemhuis wrote:
>  
>  - I'm not in rel-eng, thus
>  
>  -- I was unsure how to best fix it, as "mail rel-eng@" is used on 
>  multiple pages in the wiki; creating a dedicated "how to contact 
>  rel-eng" page seemed and seems like the best to me, but that is more 
>  than a small change thus someone from rel-eng should do it or ACK it
>  
>  -- I don't know anything about the issue in question besides what is 
>  written in the (quite old) mail jwb pointed to. Thus I'm didn't feel 
>  familiar with the issue enough to do changes as those easily might have 
>  been wrong or obsolete just a few minutes later in case someone enabls 
>  the mail-> trac gateway again
>  
>  - I just had hit the "log-out" button in the time-tracking system at 
>  work one or two minutes earlier and send the mail right before driving home 
See, a mail like this, to rel-eng, or the the devel mailing list, would
have sufficed.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Josh Boyer]

On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> Hello,
>
> I understand why rawhide should be frozen at some points, but sometime
> there is a package one really wants, that is built in koji, but not
> available in rawhide because it is frozen. In my case, for example,
> rpm-build is broken but aleady fixed. So maybe it would be worth having 
rpm-build the program is broken?  How long has it been broken?  Did you
file a bug?  Did you ask the package maintainer or rel-eng to include the
fixed version in the freeze tag?

josh

[Patrice Dumas]

On Fri, Sep 26, 2008 at 08:03:45AM -0400, Josh Boyer wrote:
>  On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
>  >Hello,
>  >
>  rpm-build the program is broken?  How long has it been broken?  Did you
>  file a bug?  Did you ask the package maintainer or rel-eng to include the
>  fixed version in the freeze tag? 
It was just an example... I filled a bug, but it was already fixed (as I
said) and looks like Jindrich already asked rel-eng.

--
Pat

[Josh Boyer]

On Fri, Sep 26, 2008 at 02:12:52PM +0200, Patrice Dumas wrote:
> On Fri, Sep 26, 2008 at 08:03:45AM -0400, Josh Boyer wrote:
> > On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote:
> > >Hello,
> > >
> > rpm-build the program is broken?  How long has it been broken?  Did you
> > file a bug?  Did you ask the package maintainer or rel-eng to include the
> > fixed version in the freeze tag?
>
> It was just an example... I filled a bug, but it was already fixed (as I
> said) and looks like Jindrich already asked rel-eng. 
Yes.  And I made an example of your example.  I'm not 100% certain, but I
think the Beta is already syncing to the mirrors, so it's quite possible it's
too late for Beta.

If things are broken in the frozen rawhide, and there are known fixes for them
then it is up to the users and developers to get rel-eng to get those fixes
pulled in.  Rel-eng and QA work really hard at trying to test and bug people
for fixes, but there is no possible way for them to test everything.

Freezes and releases need participation from both sides in order to work well.

josh

[Patrice Dumas]

On Fri, Sep 26, 2008 at 08:18:54AM -0400, Josh Boyer wrote:
>  
>  If things are broken in the frozen rawhide, and there are known fixes for them
>  then it is up to the users and developers to get rel-eng to get those fixes
>  pulled in.  Rel-eng and QA work really hard at trying to test and bug people
>  for fixes, but there is no possible way for them to test everything.
>  
>  Freezes and releases need participation from both sides in order to work well. 
Maybe rpm-build was a bad example since pushing it to the beta may have
been better. However, I won't require a human intervention on many of the 
packages I use, that have bug fixed during the freeze, because they are 
niche packages, and don't have (in general) integration issues. And in
fedora there are now many of such packages and it is growing very
steadily.

Looking at my personal case, which is certainly very specific, there are
maybe 15 over 125 I watch that should be frozen, in my opinion.

--
Pat