You Need Fedora Legacy!! Re: looking at our surrent state a bit

On Mon, Nov 06, 2006 at 08:21:26AM -0600, Rex Dieter wrote:
> David Eisenstein wrote:
>  
> > Fedora Board, please take heed.  Although
providing a stable, long-term
> > operating system/environment is *not* one of
Fedora Project's stated
> > goals, the practical lifetime of a Fedora release
of 1 year (without
> > Legacy to be there to security-maintain them for
(at least) 1 more year)
> > is ...  ridiculous -- except for the Linux
enthusiast and those who love
> > sliding down the razor-blade of computing.
> > 
> > The Fedora Legacy build team seems to be down now
to 1 or 2 builders who
> > can push packages to Legacy's updates-testing and
updates.
> 
> OK, I'll bite.  What do you want exactly from the
Board?  
> 
> Wave our magic Fedora wand to produce more (active)
community contributors? 
> OK, lemme see, now where did I leave that darn thing...



I don't know if the board has power over suggesting to
Fedora's
sponsor, Red Hat, to resuffle its engineering resources, but
if so,
then it's a simple equation: If FL is indeed going to get
more
resources to prolong a Fedora release's lifespan then these
resources
need to be drained from somewhere. This can't be rawhide and
the
latest release, but maybe the previous release (like in this
timeframe
FC5). And it can't be Rex' magic hat either, I think it only
produces
rabbits and not yet FL contributors. ;)

There are a couple of non-security/non-bugfixes updates
happening in
FC5 right now, that maybe could had been cast into FL4
support.

And in the context of sparing resources FL would have to
narrow the
support matrix to only one FL release. E.g. better to have
good
support for one release than only half for two. That drops
half a year
of support, but gains more trust back to FL if security
issues within
a release can be addressed for that other half year in a
timely
fashion.
-- 
Axel.Thimm at ATrpms.net
--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Axel Thimm wrote:

> I don't know if the board has power over suggesting to
Fedora's
> sponsor, Red Hat, to resuffle its engineering
resources, but if so,
> then it's a simple equation: If FL is indeed going to
get more
> resources to prolong a Fedora release's lifespan then
these resources
> need to be drained from somewhere. This can't be
rawhide and the
> latest release, but maybe the previous release (like in
this timeframe
> FC5). And it can't be Rex' magic hat either, I think it
only produces
> rabbits and not yet FL contributors. ;)

Board can make suggestions, yes. Dictate, no.  The board
doesnt have the 
resources in hand to allocate to sub projects. It can set
policies and 
thats the primary work that's being done. If it comes to
resources, 
reshuffling wont work since there is noone working on the
previous 
release that is not working on the current release of Fedora
and rawhide 
too. Its all part of the common pool. If we pull people out
of that, we 
would effectively reducing the amount of movement forward.
It would be 
possible to recommend that Red Hat hire *new people* to work
solely on 
legacy but justifying that is harder compared to active
upstream or new 
release development.

Unifying and opening up more of the infrastructure and other
ideas like 
that only doing critical security fixes are things to look
at.

Rahul

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

On Tue, Nov 07, 2006 at 11:46:37PM +0530, Rahul Sundaram
wrote:
> Unifying and opening up more of the infrastructure and
other ideas like 
> that only doing critical security fixes are things to
look at.

But FL's charter is already to only cater about security
fixes, or do
you imply to categorize them and allow some to slip? E.g.
allow local
priviledge escalation, but fix remote exploits?

I don't think that's a good FL manifesto. Allowing
non-critical
security issues to exist will only harm the project's front
to the
public more.

The issue is also not the infrstructure IMO, it's simply
lack of human
resources and either someone needs to assign them to it if
that entity
(Red Hat/board/whatever) considers that a worthy goal, or
the
resources need to come from more voluntary people, e.g. FL
needs a
marketing manager.

Or the need for resources is cut by reducing the number and
time span
of supported releases.
-- 
Axel.Thimm at ATrpms.net
--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

On Tuesday 07 November 2006 16:47, Axel Thimm wrote:
> The issue is also not the infrstructure IMO, it's
simply lack of human
> resources

Well, if the barrier to contribute was lower, getting more
people would be 
easier.  If it were say as easy as using the Extras build
system so that any 
current Extras contributor could easily become a Legacy
contributor as 
well...  This is what I'm working towards.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key         
(geek.j2solutions.net/jkeating.j2solutions.pub)
--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Quoting Axel Thimm <Axel.ThimmATrpms.net>:

> The issue is also not the infrstructure IMO, it's
simply lack of human
> resources and either someone needs to assign them to it
if that entity
> (Red Hat/board/whatever) considers that a worthy goal,
or the
> resources need to come from more voluntary people, e.g.
FL needs a
> marketing manager.

I think it is both Infrastructure and lack of humans, plus
stupid barriers
that shouldn't exist.

The learning curve is high, people look down at volunteers
just because
they don't/won't/can't use some technology (e.g. IRC), and
there is little
effort expended to get people to participate (though much
flaming people
for not participating).

There is also an emphasis on getting people to only help
with QA, which
is rather bad.  If you can get people to start helping
however they
feel they can, they will generally and eventually start
helping in
other areas.  But people generally need encouragement, and
not flame
wars, insults, and barriers.

> Or the need for resources is cut by reducing the number
and time span
> of supported releases.

An option, but it only makes the limited resources go
further, when what
we really need are more resources...

> --
> Axel.Thimm at ATrpms.net

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

On Tue, Nov 07, 2006 at 04:54:34PM -0500, Jesse Keating
wrote:
> On Tuesday 07 November 2006 16:47, Axel Thimm wrote:
> > The issue is also not the infrstructure IMO, it's
simply lack of human
> > resources
> 
> Well, if the barrier to contribute was lower, getting
more people would be 
> easier.  If it were say as easy as using the Extras
build system so that any 
> current Extras contributor could easily become a Legacy
contributor as 
> well...  This is what I'm working towards.

It's certainly worth while attacking this way, but I think
it will not
be enough. Let's hope I'm wrong.
-- 
Axel.Thimm at ATrpms.net
--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Axel Thimm wrote:
> On Tue, Nov 07, 2006 at 11:46:37PM +0530, Rahul
Sundaram wrote:
>> Unifying and opening up more of the infrastructure
and other ideas like 
>> that only doing critical security fixes are things
to look at.
> 
> But FL's charter is already to only cater about
security fixes, or do
> you imply to categorize them and allow some to slip?
E.g. allow local
> priviledge escalation, but fix remote exploits?
> 
> I don't think that's a good FL manifesto. Allowing
non-critical
> security issues to exist will only harm the project's
front to the
> public more.

Not really. It is better than not pushing updates at all.
See 
https://www.redhat.com/archives/f
edora-security-list/2006-October/msg00006.html


> The issue is also not the infrstructure IMO, it's
simply lack of human
> resources and either someone needs to assign them to it
if that entity
> (Red Hat/board/whatever) considers that a worthy goal,
or the
> resources need to come from more voluntary people, e.g.
FL needs a
> marketing manager.
Lack of human resources is also a result of higher barrier
to entry. New 
people need to be able to contribute easily. Existing
contributors in 
other sub projects like extras need to able to do that.
Unifying 
infrastructure and automating more of the tasks helps in
both ways.


> Or the need for resources is cut by reducing the number
and time span
> of supported releases

Just as reducing time span is a option, classification of 
vulnerabilities and working on critical ones after a time
span is also a 
option that needs to be considered.

Rahul

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Eric Rostetter wrote:
> Quoting Axel Thimm <Axel.ThimmATrpms.net>:
>
>> The issue is also not the infrstructure IMO, it's
simply lack of human
>> resources and either someone needs to assign them
to it if that entity
>> (Red Hat/board/whatever) considers that a worthy
goal, or the
>> resources need to come from more voluntary people,
e.g. FL needs a
>> marketing manager.
>
> I think it is both Infrastructure and lack of humans,
plus stupid 
> barriers
> that shouldn't exist.
Agreed... getting people to participate is one thing, but
the effort to 
contribute is a bit high at the moment, considering that
most folks are 
making this part of their spare time...

It's also about organizational leadership, which to be
honest, I do find 
lacking... there is no specific plan, no
accountability/responsibility, 
no visible means to release into testing and production. To
be honest, 
Legacy is pretty much borken as an organization at the
people level.

Folks want/need to know what to do, who does what, and how
things work. 
This may be an implied thing at the moment, but speaking
from somebody 
looking in from the outside, I have to ask why bother?

1) Packagers - this is important obviously
2) Testers - packagers should not be testers, but testers
should be defined
3) Releaser Management - once QA is done, somebody needs to
release the 
package to the production tree...

The three roles are very different, and these need to be
filled by 
different people, i.e. no overlap in responsibility...

> The learning curve is high, people look down at
volunteers just because
> they don't/won't/can't use some technology (e.g. IRC),
and there is 
> little
> effort expended to get people to participate (though
much flaming people
> for not participating).
The bar is pretty high to get in, and this is intimidating
for those who 
lack experience with items outside of the course of their
normal usage. 
Not to say that folks could not rise up to the challenge,
it's just that 
the path is poorly documented, and the tools are, to be
honest, a bit 
tough to use. Again, it comes down to who and how...


> There is also an emphasis on getting people to only
help with QA, which
> is rather bad.  If you can get people to start helping
however they
> feel they can, they will generally and eventually start
helping in
> other areas.  But people generally need encouragement,
and not flame
> wars, insults, and barriers.
Bingo... thing is that QA is the end of the line, and the
one most 
needed and least respected by the folks that build packages.
One thing 
that is very important, as the base of folks that would be
potential QA 
candidates is to:

1) spell out what is needed - what is the problem and fix,
how to test it?
2) how to use the systems - how to mark tested, reopen, open
new bugs

For the packagers... how to package for a release. I
maintain my own 
boxen, so when a security issue pops up, I download source
or make the 
fix locally. How to build a package and release it into
testing remains 
somewhat of a mystery... I'd be happy to do so, if it were
documented 
somehow.

>
>> Or the need for resources is cut by reducing the
number and time span
>> of supported releases.
>
> An option, but it only makes the limited resources go
further, when what
> we really need are more resources...
More resources is not the answer - better management of the
resources 
that are on board, and better tools to manage the process is
what is needed.

The process itself needs to be defined and clarified.

Tim

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Eric Rostetter wrote:
> Quoting Axel Thimm <Axel.ThimmATrpms.net>:
> 
>> The issue is also not the infrstructure IMO, it's
simply lack of human
>> resources and either someone needs to assign them
to it if that entity
>> (Red Hat/board/whatever) considers that a worthy
goal, or the
>> resources need to come from more voluntary people,
e.g. FL needs a
>> marketing manager.
> 
> 
> I think it is both Infrastructure and lack of humans,
plus stupid barriers
> that shouldn't exist.
> 
> The learning curve is high, people look down at
volunteers just because
> they don't/won't/can't use some technology (e.g. IRC),
and there is little
> effort expended to get people to participate (though
much flaming people
> for not participating).

I, for one, appreciate the hard work that you do, Eric.

What do you suggest as an alternative for IRC for folks who
are not able or
interested in using it?

	Warm regards,
	David Eisenstein

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list

Quoting David Eisenstein <deisenstgtw.net>:

> What do you suggest as an alternative for IRC for folks
who are not able or
> interested in using it?

I work in several opensource projects that have IRC
channels, and I've never
used IRC for any of them, and no one has ever complained
about that fact
except for here on FL.

Instead, I use e-mail (the project mailing lists in all
cases, except for
here on FL where I sometimes use private e-mail also). Not a
real big fan
of the private e-mail, but it works here for some FL stuff.

I've never had any lack of ability to do anything I wanted
using e-mail
instead of IRC on any of the projects I've worked on.

I'm not knocking IRC.  It has some limitations though, such
as timezone
issues, etc.  Plus, some of us work on FL stuff at work, and
IRC may be
blocked at our work place or disruptive to our work.  This
can be a real
issue for some of us.  Hence, I never use IRC/IM at work,
and hence since
99% of my opensource work is done at the office and not at
home, that means
I really can't use IRC/IM for these projects.

Now, I think IRC is very useful for some things.  For
example, if you have
a "board" or "core" group that has
regular meetings, IRC is a great way
to have those meetings.  But for the typical FL user who
isn't a core/board
member, it is overkill.  And I just don't see why I should
be forced to
install (IRC) software on my machine, learn how to use it,
wonder if the
University Network Folks will come knocking on my door
because of it,
and let it disrupt my work, just so I can ask a question
that I can ask
via e-mail.

Now, e-mail lists have advantages also.  A nice, searchable
archive of the
messages for reference by others, reference for myself
later, and as a
source for creating the documenation on the issues addressed
there.  Plus
of course the asynchronous nature which allows people in all
different
time zones to participate, etc.

So I'm not for getting rid of IRC, just for making it an
additional option
and not a required option.

> 	Warm regards,
> 	David Eisenstein

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!

--
fedora-legacy-list mailing list
fedora-legacy-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-legacy-
list