suggestion: move all java packages to extras

Arjan van de Ven arjan at fenrus.demon.nl
Sun Nov 27 18:17:52 UTC 2005


On Sun, 2005-11-27 at 17:56 +0100, Dennis Jacobfeuerborn wrote:
> Arjan van de Ven wrote:
> ...
> ...
> >> This is what I'm talking about - right now the distinction b/t what gets
> >> into core and what goes into extras is more or less 'where does the
> >> packager work'
> > 
> > then I don't agree with how that works and would favor and advocate a
> > more "functionality" way of looking at it.
> 
> How is looking at the problem in different ways going to solve the (in my 
> eyes unsolvable) problem of choosing one specific implementation of a 
> "media player" or "office suite" for Core? In order to do that you would 
> need an entirely objective argument why dovecot is more entitled to be in 
> Core rather than cyrus-imapd and I never see that happen in all the "what 
> should be in Core" dicussions that transpired so far.


not chosing however is worse than picking either. Having worked for RH,
I can say that this is hardly done arbitrary, but based on things like
feature set, code quality, security evaluation, customer requests etc.

You can argue hours and hours about "but X has feature Y" or "but we
need X because Y has bug Z" (the later imo is a bad reasoning, fix Z
instead). But at the end of the day, a choice needs to be made for Core.
Sometimes Extras should end up with the "loosing" half. Sometimes not
imo; several of the things dropped in the last years were for security
reasons, putting it into Extra then is not better. 

I'll go a step further. Choices like this need to be made by architects
to ensure consistency etc. Not a community forum where the one with the
loudest voice wins. Don't get me wrong, there is absolutely a role for
the community in this, both in setting the objectives for this
"architect" to base the decisions on (like what the criteria should be,
and what functionality is suitable for core, and even suggestions about
packages) but making the final call between package A and package B is
not something the community is good at, just look at the debian package
list. There will never be agreement, there are too many stakeholders who
care only about package X without considering the big picture, the ones
with the loudest mouths win or force something etc, all leading to not
the best decision. 

So "someone in Red Hat makes a decision" is not the problem. Unclear
criteria, lack of "what is suitable functionality for core" policy etc
is a problem (you can argue how big a problem it is of course).





More information about the fedora-devel-list mailing list