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
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 dev
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
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
> wou
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 o
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 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 secur
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 c
-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. W
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
--
T
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 sid
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 ag
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 return
-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 lo
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
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.
>
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.
Gr
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 do
-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
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 delicat
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
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 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 prio
23 matches
Mail list logo