Re: where do NEW packages go?
On Sun, 19 May 2002, Jeroen Dekkers wrote:
> It doesn't really matter how it was created, it matters what is is today.
What do you mean by this? Don't dance around the issue.
> Are just so smart that you got all patches right without discussion,
> or is there just some secret document which describe the steps to get
> an idea discussed?
At the time, I was extra careful, and made certain that what I was doing was
what was wanted. I also picked relatively simple issues, that needed to be
done, but seemed like no one had the time to do them.
Since then, I've made mistakes(the brokenness of dpkg-source last summer), but
we are all human.
> True. That's why you need feedback from the developers of those tools
> before writing patches, because it's likely you do it wrong. If you
> never get that feedback, you can never implement the feature you
> want. If it's a low priority item for the developers too, it probably
> never gets implemented. That's why I call it a cabal.
As an analogy, let's go back to when I became a developer(jan '98). This was
during the libc6 recompile(or libc5 recompile, I forget which). I had just
sent in my application, and then started recompiling packages for the new c
library. I was doing 3-5 new packages each day, and posting a nightly summary
to -devel. After a few days, I had several developers on that list clammering
for me to be added to debian, so that those packages could get uploaded.
I didn't pester new maintainer(it didn't exist in it's current formalize form
back then). I just started doing work, that was needed. And kept doing it,
until I was accepted.
(I did do some things wrong during that recompile frenzy. I mistakenly set
debian/control:Maintainer to me, because I didn't fully understand how NMU's
were supposed to be done).
What I am saying here, is that you do work that *needs* to be done, when no
one else is doing it. You don't invent new work, and new requirements, but do
existing work.
The volume of work you do, if mostly good, will speak for itself. You don't
even have to be 100% perfect when doing so, if your heart means well(and, you
aren't completely moronic, and at least show some promis).
Spouting off on lists, saying "I am respected elsewhere, I should be respected
here, damnit!" will do the exact opposite of what you intend.
> Are they told the procedures? Are those written down somewhere? You
> can't just think that everybody knows them, AFAIK it isn't part of the
> NM process. Maybe it would be good to add this...
There is seldom time to write them down. Maybe you should volunteer to do
that. Install the software that these groups use. Learn how to use it.
Write down what you have learned. Rewrite it into a HOWTO and/or FAQ.
Then, erase your mind, and follow your own HOWTO and/or FAQ. See if they are
complete. Fix if not.
When that is done, send what you have accumlated to those in charge, and see
what they say.
> True. But I don't see why they can't add those packages to the
> override file or give somebody of Debian GNU/Hurd access to it so he
> can do it for the Hurd port. I think there are at least some
> developers who already have earned enough respect to do this.
There's a trust issue invovled here. CIM(you do know what that is, don't
you?) requires notifications to be sent to the US gov't for ALL new packages.
This slows things down. Additionally, once you get past the CIM requirements,
adding a new package means it will be made available thru the mirror network.
You can't have random crap put on that, as it may be a trojan, or something.
I'm not saying all new programs are bad(or that even some are), but these
things are what must be considered. It's not about having someone available
to run some software, or edit some file. It's about trusting the person to do
what is right.
> No, I want to show you how you think. People keep telling 'the Hurd
> should be ported to Debian instead of Debian to the Hurd'. The fact is
> that the Hurd isn't our next new editor, but GNU/Hurd is a complete
> other OS. That's kind of a difference.
>
> I can also tell it on your level, if you understand that better: You
> are just too stupid to understand the difference between our next new
> editor and new OS in Debian. (Well, I agree that with emacs it's not
> really that clear :-)
I know how *I* think, thank you very much.
And, you still do not get what I meant. You keep on construing it to your own
twisted meaning.
> Have you actually ever read arch-handling.txt? It was written in
> 1999.
Does it matter? Really? How stable was hurd back then? What hurd ready to
be unleashed on the wild?
As someone else has suggested, hurd might want to fork the few critical
packages in Debian that require modifications; apply the fixes the hurd needs;
use them in the real world. After they have been in the wild(on hurd systems)
for X amount of time, and there have been no issues, then approach the package
maintainers with your summaries.
> Are you sure? GNU/Hurd = the GNU system, started 7 years (or more?)
> before Debian was started or Linux was created. There have been more
> developers hacking on that than on Debian.
No, GNU is GNU, GNU/hurd is GNU working on top of hurd. The '/' between the
words means they are separate, not one.
The same analogy goes for GNU/Linux. And, by extension, Debian GNU/Linux.
> But we were just talking about respect here, not about procedures. So
> care to explain why I don't get respect in the Debian community and I
> do get respect in the GNU community?
I think it is apparent by your emails.
> Your first mail:
> "But, I shouldn't say more, as it may clue you in on what I am talking
> about here. You should find out for yourself."
>
> I parse that as "You are just stupid and don't know where you are
> talking about, maybe you will find it out when you grew up".
You parse it correctly.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: