> > Who will decide which packages are first-class citizens and which are not? > > What are the criteria? > > I suggested a few. > - Is a developer willing to commit to maintaining it? > - Is it expected to be fairly popular, or is it extremely specific? > - (for apps already in the tree) Is it unmaintained? Should it be > moved to an overlay?
The first criteria is naturally a prerequisite for any package. But I also share the concerns raised by Andrey. Somehow, I feel, personally, that the sci-packages should constitute an exception from the general rules regarding overlays. I mean that when a person chooses to use something from, say, Xfce overlay, the use of an overlay is rather natural and pleasant, but when a person is "forced" to use an overlay in order to write a Ph.D thesis, the use of an overlay can be far from pleasant. In my opinion overlays can not escape additional concerns regarding quality and trust, and these concerns are much more strongly felt when we are dealing with scientific packages. Again the keyword may just be the perception. And as Sébastien mentioned, this is an area in which the build process and runtime behavior should be rock solid, the former preferably being accompanied by as many tests as is possible. Do not get me wrong: all packages that I have used from the sci-overlay have been high-quality ones, but for the mentioned reasons I see no point in having an overlay that possibly (would? will?) contain unmaintained ebuilds with little or no testing. Again I see this as an issue specifically related to the scientific packages. Also, given that we are dealing with scientific software, the minority of the packages will fall under the "generic and popular" category, while the rest will surely be more or less specific. I see that we have eleven sci-categories in the main tree. Most likely packages in sci-electronics will be extremely specific for people doing work with packages in the sci-geosciences category. I doubt that popularity is such a good criteria in choosing which scientific packages deserve to be in the main tree. I would rather like to ask what kind of internal representation the sci team has? Are the staffing needs especially bad in some areas? Again these were just small and perhaps irrelevant opinions from an user of the scientific packages. Thanks, Jukka Ruohonen. -- [EMAIL PROTECTED] mailing list
