On Fri, Nov 05, 1999 at 12:18:35AM +0100, Sami Dalouche wrote:
<snip>
>
> I wanted to compile the new mutt + GnuPG. hmmm.. I had to compile the new
> slang before. It worked. Great. But it asked for the new debhelper too !
> Aie, I tried to compile the .deb from the sources and it didn't work. It
> made an error concerning perl or something like that. AH, so I could maybe
> have to compile the new perl, and maybe the new libc, and everyhing. But
> because potato isn't only an unstable distro but has a majority or
> unstable (or CVS) software (eg Xemacs 21 was CVS a few time ago), my slink
> system would become an unstable one ! So, it's not appropriated !
I realise this can be a painful situation - but I don't think the solution is
as easy as you may think...
> * upgrade to the unstable branch ! And I tried during the unstable
> days ( a small time before perl upgrade, when libc2.1 was completly
> unstable ) : All my X software were crashing, I had kernel crashes due to
> X.... So, it can't be used for a normal platform !
This is why it is called "unstable" :)
>
> Instead, we should make 3 distro called "server" ; "normal" and "experimental"
>
> The "server" distro would be an extremly stable one ! It shouldn't contain
<discussion of "server" distro snipped>
The server distro is a nice idea - but it is neigh on impossible to guarantee
there are _no bugs_ in a distribution. IMHO the security team does a great
job of fixing security related bugs in our stable distribution - which is
where the major concerns would be anyhow. But getting developers to
hyper-focus on bugs in this system would be ridiculous - particularly as most
of us would run "unstable" distributions.
> The second distrib would be called "normal". To summarize, it would be a
> distrib that contain the stable upstream versions, and, if the software or
> the maintainer thinks it's useful, the unstable one. But the upstream stable
<discussion of "server" distro snipped>
This is the situation of our current "stable" branch - albeit minus a few
"latest release" packages. But if a developer feels a latest release package
is useful for the "stable" branch, then they (or someone) will often produce
a version targeted at this platform (for example, gnome).
>
> I think you have now unserstood the general goal of this distrib, so let's
> speak about the "experimental" one
<experimental description removed>
Ok...so your now saying our main development platform has to be totally
experimental. Forget it. Most of us are developers who run an "unstable"
distribution at home, and we are happy enough to put up with the few
difficulties in running it, since we can help to fix them. But none of us
really appreciate a totally untested "experimental" package destroying our
systems.
And IMHO I don't think many developers would have a) enough hard disk to run 2
distributions, nor b) enough bandwidth and time to reinstall the experimental
one each time it breaks.
I'm sorry, but there is nothing in this proposal that sounds workable to me.
ATM we work hard to build a good, solid distribution - which we then release
to the public. Once it is released we all have a party, a few drinks, then we
leave it and move on (starting a new "unstable"). Because we a part time,
volunteer developers, we can't be continually supporting three different
development trees. Instead, we concentrate our efforts on one - and we make
it the best in its class when it is released. To try and do more would put
me, and many other developers, out of the project.
> : Bug fixing.
> A maintainer that doesn't fix his bugs for any reason should be fired ! When
> a developper thinks another developper doesn't do a good job, he could send
> a mail to debian-devel, with a subject like "Intend to fire : Name Of The
> Guy" and explain his reasons. ANd if the man doesn't explain his attitude,
> and if at least 50 developpers (for example) agree with the IT fire, the man
> is fired ! As a result, we would only have developpers that trust in debian
> and want debian to be a better distro. But it should be easier and faster to
> become a developper. Provided that we can fire the developper, everyone
> could become a developper if he wants to add something into debian. The
> Maintainer guide should of course warn the new developper that he must do a
> good job, and that the debian team knows his identity (the subscribtion should
> continue to ask for an identirty card) and he musdn't become a developper
> for hacking reasons.
Ok..please note I haven't snipped this out.
Are you crazy?
This has to be _the_ most wrong thing I have heard suggested in a long time.
The debian community is about people getting together, _donating_ their time
and effort in the hope that we can build something better. What you are
suggesting is to turn this into a highly agressive, fast paced, back-stabbing
institution, and I for one wont stand for it.
Not everyone has the time to be 100% committed to debian. We have lives in
the "real world" (No offence to those of you who do practically live for
debian - I honour your dedication to _our_ cause). But when it comes to
development (be it bug fixing or whatever), I will always put in what I feel
like, and no more. If I was made to do more it would no longer be fun, and I
would leave. But if what I could provide is not good enough for you, then you
would kick me out of debian - despite me being a dedicated developer.
And what have you achieved by doing this? You've lost a dedicated developer,
and you still have un-fixed, now homeless packages. Are you going to take
them all on? Forget it - instead of wasting time working out how to punish
us for not giving what _you_ want, join in and help us get more done. If I
have a month outstanding bug report, then by all means fix it for me, and send
me the fix. You've just put in the work that I haven't had the time for, and
made debian better for it.
> We shouldn't hire developper that live inside
> countries were hacking is legal, of course :))
(I assume you mean cracking, since I would bet most developers would call
themselves hackers.)
Now you want to make debian become a politically racist organisation??
So if I lived in a country that happened to take a lenient view on
"cracking", I would be immediately denied the chance to help out in a project
I am interested in and willing to devote time and effort to? Debian cannot,
and should not, discriminate potential developers based on location, race,
color, language or anything. To do so would go against the whole nature of
what we have, a "world-wide" volunteer organisation.
<snipped commentary on release numbering...I'm not even going to bother>
> I think I have finished explaining te BIG debian problem. So, please
> consider what I wrote instead of saying it's right while nothing changes.
Don't worry - I wont say "it's right", nor will I ignore it.
> (Ah ! Another Debian problem : changing something is impossible. Even if
> it's great, there is a Policy chapter saying that X or X thing is impossible
> ! Please stop only think through the policy, think before about the proposed
> idea, think after about the policy and legal side. If the policy forbits
> something which is cool, just change the policy, it's nothing else than some
> words added together in a text file....)
This "text file", as you so casually put it, is our guidelines for what we are
trying to achieve. Without it we would be merely stumbling in the dark, and
would have achieved nothing that we have now. We (ok, not me personally - but
many developers) have had huge discussions getting this "text file" to reflect
what is considered best for debian. And if you do have a "cool" idea, then
post it to debian-policy, and if a consensus is reached then it will be added
in. It is not impossible to achieve change in debian. You just cant do it on
your own, when you feel like it, without discussing it with everyone first.
> Hoping you will think at my idea,
> sami
I have.
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpdJfuE6n3CG.pgp
Description: PGP signature