Re: [interal+desktop]Re: [desktop] RFD: Can DeMuDi and Desktop
On Wed, 23 Oct 2002, marco trevisani wrote:
> i do agree with Andreas about the fact that any project and sub-project
> should contribute to the all Debian community, at the same time i dont
> see why (sub)projects with common goals should not join forces as Luke
> suggested, with no intention of make an isolated project, on the
> contrary to benefit the all Debian community.
The only reason why I mentioned that this kernel project should not be
tagged as a subproject aim was, that it might prevent some people who
are not really concerned to the subprojects might think: Hey, what are
those sub-project people doing. If it is only interested for them I
could do other things because I'm just interested in kernel-modules
not in subprojects.
If someone notices: Debian is missing this or that package than he
should file a Bug-Report as I described in
http://lists.debian.org/debian-med/2002/debian-med-200204/msg00091.html
Fullstop here.
The description might contain a side note that this package is interesting
for this or that sub project. I'm afraid that tagging a package explicitely
as a sub-project issue might hide it from the view of other developers.
If someone is interested and find some other developer to cooperate it
is really fine. But I see no reason to tag a normal Debian package to
a certain issue.
> I really would like to join forces, with the desktop project since, as
This is really sane and I expect that I will copy more or less certain
parts of the desktop project for Debian-Med. This is the core of the
idea: Building things we need and use them for the profit of our users.
> they might have interest in our kernel development we are also
But I see no sense in making kernel development to an exclusive target
of the sub-projects. This is what I mean with: "Using solid Debian
infra structure for the profit of the internal projects." Let Debian
care for the basics (by just filing an RFP-/ITP-bug and grab the work
if noone else steps in yourself).
> interested to provide an easy to use desktop (see my *extra large* email
> on the subject) without compromising computer efficiency, for instance
> without introducing too much latency, as we noticed on our test about a
> year ago.
I personally do not know anything about those interesting stuff but
I fail to see any reason why this should not be a general Debian
interest. Why is no RFP-/ITP-bug filed to the BTS?????
> the Desktop package could have various level of recommendation: 1)
> works with any Debian kernel, 2) better if user apply low latency
> patches, 3) best with DeMuDi kernel+low-latency+preempt images.
Fully agreed here.
> [ It goes without saying the nobody denies anybody to use the DeMuDi
If anybody could than it would have to go into non-free and thus it
would not be a part of Debian. :)
> kernel with Debian-junior/med/edu or whatever without installing DeMuDi,
> such kernel is perfectly compatible with Debian, and we do not package
> any kernel image if it is not on Debian first. The fact that comes with
> *DeMuDi* in the package name it is just to differentiate from the Debian
> packaged kernel but it is a multi-purpose kernel].
... and the naming should be apropriate to not confuse users. This is
what I wanted to adress. Do not confuse users and developers by
improper naming. Just build a general package
kernel-<some_wonderful_and_nifty_stuff>_<version>.deb
and let a demudi-kernel package depend from it. Everything else would
be confusing IMHO.
> As Andreas said a sub project goal should be to create an environment
> for the topic of the project with the existing Debian packages. This is
> true and it is at the same time what makes DeMuDi integration a bit
> harder/slower
Sure. Making things right ist time consuming in the beginning. I never
denied that.
> because sometime the existing Debian package is not enough
> for what we are doing.
I know that.
> Let me give a couple of examples. We need to
> package and make a module package for latest cvs ALSA, since some pro
> cards (USB and PCMCIA for instance) are available only in cvs. First i
> contact the Debian maintainer, if (s)he does not respond or (s)he is not
> interested, as it happened in this mentioned case --I'm not blaming the
> maintainer, far from me this idea, again this is part of the way Debian
> works and should keep working this way-- we must package ourself ALSA
> for DeMuDi.
I understand that it might be a hard job to file a bug report against
a certain package with patches which do not conflict with the package
maintainers interests. But in the end *all* Debian users and developers
are interested in the best possible packages. The purpose of the
debian-devel list is to discuss technical issues. If you do not agree
with the maintainers (technical!) point of view and he is ignoring
your patches feel free to discuss it here.
Yes, this is time consuming but in the end it makes Debian better and
makes it fit for your special purpose. I have no problem if this does
not fit your short term time scale. But I have the very strong feeling
that it leads to an optimal solution in a long term scale.
> Plus all DeMuDi core applications needed to be tuned a bit
> because we use Jack as sound server, and you can't ask maintainer to
> necessarily follow us, even if it will come back to Debian somehow
> because these changes required a strict cooperation with upstream
> authors and changes will be soon become part of the applications and by
> consequence all Debian community will benefit.
I really regard you DeMuDi people as very well informed about sound issues.
I never dealt with this stuff until I've got the sound I wanted to hear
from my speakers and did not investigate a single minute in optimizing
it. But I would really love if those educated people as you would make
some efforts to find *the best* free technical solution the default
for Debian. Perhaps we just were missing real sound experts and noone
took over the effort to make it better. (I hope not to offend the
maintainers of the sound packages. I never had real problems and I'm
speaking as a pure ignorant of sound issues. But obviousely there are
things missing we would need ...)
> In the mean time we can't
> wait for this circle to be completed naturally because DeMuDi has also
> deadlines, since we have, luckily received a EC grant. Just to say that
> DeMuDi is in a strange position as sub project.
No. You have to care for your deadlines. Just continue to work for
it. The only thing I want to adress is that you will have less trouble
to reach your deadlines in the future if you split up the necessary
work reasonably to as many competent shoulders as possible. Let kernel
experts work for kernel issues and care for the stuff you are an expert
in.
> Sorry i dont know why every time i write it ends up to be such a long
> message, maybe is because I'm always in a hurry and very little time for
> email...
Ditto :)
Andreas.
Reply to: