Fedora Core 2 wishlists

[Gene C.]

On Monday 08 December 2003 10:15, Michael K. Johnson wrote:
> I'd like to
> hear people's wishlists.  Not everything will be possible, but it would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.


OK, my wishlist --

1.  Full AMD64 support ... this should be a goal for FC2 but with the idea 
that it would be certainly done by FC3.  By full AMD64 support I mean the 
ability to build/install Fedora Core on an Athlon64 or Opteron with a 64-bit 
kernel and both 64-bit and 32-bit libraries so that you can run both 32 and 
64 bit applications.  While we may be able to get partially there for FC2, it 
may take more time to get all libraries correctly configured.  If at all 
possible, the i386 and AMD64 versions should be issued at the same time.

2.  SELinux ... "enabled" in all binaries but not turned on by default.  No 
recompiling packages necessary although you might/will need to install some 
extra packages.

3.  Integrated up2date/redhat-config-packages ... I understand that 
redhat-config-packages is currently undergoing redesign from a blank piece of 
paper.  The new package should be capable of getting input via http, ftp, 
local directory trees, iso images as well as cdroms (this last one is a soft 
requirement by me).  I should be able to get updates, to install "groups" of 
packages (e.g., X Development, Gnome Development, etc), to install individual 
packages.

Currently, up2date has most of the needed capabilities but a redesign is 
probably needed to "get things done right".  Specifically, I can use up2date 
to get/install updated packages via http, ftp, and local directory trees.  
With --show-package-dialog I can install packages not previously installed 
(this only works if you have at least one pending update or hack gui.py to 
comment out the sys.exit(0) if there are no updates.

4.  Some type of triage process for prioritizing bugs which must be fixed 
before "gold".  While my opinions as an individual (or anyone else as an 
individual) who is not a Red Hat employee should not drive such a process, 
there should be something which involves at least some (non Red Hat) 
end-users.  If something cannot be fixed for "gold", then it should have 
priority to be fixed (assuming there is a fix) post official release.  This 
"post official release" is occurring but very unevenly.

Now for my pet peeves, I have fixes which work to my satisfaction.  That does 
not make them satisfactory in general nor does it make those fixes generally 
available to others.  Currently, my pet peeves are:

  - gftp handling of http does not work in gftp-2.0.14 BUT gftp-2.0.16 is 
available from upstream and that fixes most things.

  - gnome-panel drawers do not work with gnome-panel-2.4.0-3 (launchers added 
to a drawer become just pictures after a logout).  The fix is a patch to 
button-widget.c (which was available in mid September) or to use 
gnome-panel-2.4.1 ... both fix the draw problem ... but reveal another 
problem which the panel is hidden (drawers fly open).  Now, to me it is 
better to have drawers that work than to worry about the hidden panel.  
Waiting for FC2 for a fix is not reasonable to me (which is why I created my 
own ... actually applying work from upstream).

While I realize that the folks at Red Hat are a limited resource and cannot 
address everything, perhaps there needs to be some secondary repository with 
user created fixes for Fedora Core packages.  I find the current situation 
which updated packages for packages included in Fedora Core being added to 
Fedora Extras to be unreasonable!  Case in point: gftp.

5.  Fedora Extras needs to work.  If we are going to be able to shuffle of 
some packages (galeon come to mind) to Extras rather than having it in Core, 
the the process needs to work.  Currently the QA queue at fedora.us is 
clogged.  IMHO, this cannot be resolved without a different approach.  From 
my viewpoint, the fedora.us QA process exceeds that done by Red Hat for some 
of their packages.  Furthermore, doing a source-code audit of a package as an 
alternative to QA testing is a very expensive process (lots of people hours).  
Unless you really know what you are doing, I am not sure what a source code 
audit will prove.

Some extra packages are widely used but not so widely used that they should be 
part of Core ... these should go into Extras and have good QA done.  I agree 
with Warren about something needs to be done about the large QA queue on 
fedora.us but I am skeptical that a source-code audit is the answer (or maybe 
I do not understand what Warren means by a source-code audit).  

To me, testing of a package by a user does not require any special skills by 
the user -- just a desire to use the package and the willingness to do 
testing.  On the other hand, doing a source-code audit requires an individual 
with good understanding of the programming languages involved (c, c++, perl, 
whatever) as well as an understanding of what can cause problems (e.g., 
buffer overflows, not paranoid testing of parameters, etc.).

Another thought that occurs to me is that perhaps for a package to be even 
considered for Extras (even before it enters QA processing), it should have 
multiple "sponsors" who agree that addition of the package to Extras would be 
a good idea.

For the rest of the packages which are not necessarily widely used, I suggest 
that a "Contrib" category be established .. a buyer-beware repository of 
packages.  I do not know if this is a good idea or not.  Red Hat used to have 
a contrib directory and some good stuff (and a lot of crap) got put there.  I 
have not looked lately but I believe it has been discontinued.

Enough for now.  I look forward to comments.
-- 
Gene