On Fri, May 23, 2008 at 06:44:39PM +0200, Steinar H. Gunderson wrote:
On Fri, May 23, 2008 at 06:03:51PM +0200, Stefano Zacchiroli wrote:
So, basically, I welcome your proposal, but IMO its simplest and most
effective implementation would be: ``packages scoring high in popcon
have to be
On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
manage a hard meticulous QA process in all packages. In the other hand, there
are packages more critical than others, which are more delicate to
On Tue, 20 May 2008, Luciano Bello wrote:
- It should be checked with debugging tools (like valgrind :P)
- It should a public VCS
These should be encouraged, and in the cases where packages aren't in
a public VCS or QAed properly before upload, the deficiencies should
be politely pointed out
On Fri, May 23, 2008 at 06:03:51PM +0200, Stefano Zacchiroli wrote:
So, basically, I welcome your proposal, but IMO its simplest and most
effective implementation would be: ``packages scoring high in popcon
have to be maintained by teams using some Vcs-*''.
Why do you want to force the use of
El Vie 23 May 2008, Don Armstrong escribió:
- It should maintained by a team
Team maintenance doesn't automatically make a package better.[1]
Furthermore, I don't believe there are many (possibly any!) packages
in Debian where the package is important and the current maintainer
wouldn't
On Fri, 23 May 2008, Luciano Bello wrote:
Is not about accept help. It about considering the package as
unmaintained if there is not a team to maintain it. In same
packages, we can not depend on only two pairs of eyes.
If there aren't enough people who are interested in maintaining
packages
On Saturday 24 May 2008, Don Armstrong wrote:
On Fri, 23 May 2008, Luciano Bello wrote:
--cut--
Of course at first is not easy. But we should go to an scenario
where all the local patches was reported to upstream (to apply them
in the next release) or be justified by more than one
On Wed, 2008-05-21 at 06:11:46 +0200, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
even though it's just a command line utility. Who knows what
weird, unexpected side effects there might be from running such an
app within a tight bash loop.
none*. And not cleaning up
2008/5/20 Luciano Bello [EMAIL PROTECTED]:
Hi list,
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
manage a hard meticulous QA process in all packages. In the other hand, there
are packages more critical than others, which are more delicate to security.
On Wed, May 21, 2008 at 09:00:45AM +0200, Miriam Ruiz wrote:
Thinking about it again, I wonder if that could be implemented using
Enrico's DebTags. I think they would be perfect for this.
Something like #436161 would be the place to start: it's about time to
resume that work.
Ciao,
Enrico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/20/08 23:11, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
even though it's just a command line utility. Who knows what
weird, unexpected side effects there might be from running such an
app within a tight bash loop.
none*. And not cleaning up yourself also improves performance for short
running apps.
How so?
The libraries request memory from the kernel in pages (4k on i386, will vary
on other architectures), they then run thier own heap management system within
those pages. Some memory managers will
El Mar 20 May 2008, Nicolas François escribió:
It will be hard to define this list of delicate packages.
For example, I'm not sure I would have put openssl in the list a few weeks
ago.
I would have first think about setuid/setgid programs, servers, with high
popcon packages first.
I agree,
On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/20/08 23:11, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
even though it's just a command line utility. Who knows what
weird, unexpected side effects there
In article [EMAIL PROTECTED] you wrote:
What about compilers and interpreters (like gcc and perl)? Kernel and drivers?
Everything which is part of the TCB (libs, login, resolvercache, init, root
cron tools, etc).
And of course all network clients and all other programs :)
Gruss
Bernd
--
To
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/21/08 20:08, Andreas Bombe wrote:
On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote:
On 05/20/08 23:11, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
even though it's just a command line utility. Who knows what
Hi list,
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
manage a hard meticulous QA process in all packages. In the other hand, there
are packages more critical than others, which are more delicate to security.
Sometimes, those packages have different
2008/5/20 Luciano Bello [EMAIL PROTECTED]:
But I mainly want to know your opinion.
I think it would be a good idea to have something like that :)
Greetings,
Miry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
On Tue, 2008-05-20 at 17:21 -0300, Luciano Bello wrote:
Hi list,
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
manage a hard meticulous QA process in all packages. In the other hand, there
are packages more critical than others, which are more delicate to
Hi,
On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
Hi list,
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
manage a hard meticulous QA process in all packages. In the other hand, there
are packages more critical than others, which are more delicate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/20/08 18:42, Nicolas François wrote:
Hi,
On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
[snip]
For example:
- It should be checked with debugging tools (like valgrind :P)
It's not always needed.
It may show some bad
Ron Johnson writes:
Still, though, it's Bad Practice not to clean up after yourself, even
though it's just a command line utility. Who knows what weird,
unexpected side effects there might be from running such an app within a
tight bash loop.
None. If the process exits it exits. It doesn't
In article [EMAIL PROTECTED] you wrote:
even though it's just a command line utility. Who knows what
weird, unexpected side effects there might be from running such an
app within a tight bash loop.
none*. And not cleaning up yourself also improves performance for short
running apps.
Gruss
23 matches
Mail list logo
