Re: StrongARM tactics

[Steve Langasek]

On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >Um... no.  This is *porter* work; one does not have to be a buildd admin to
> >analyze a build failure to see whether the package belongs in P-a-s, and
> >there's no reason that the buildd admins alone should bear the
> >responsibility for figuring out whether a permanent build failure should be
> >fixed or ignored.  (Maintainers probably need to be involved in this
> >process, but usually maintainers don't have the requisite knowledge about
> >all our ports to make informed decisions on their own.)

> I can do the analyzing, but what should I do with the results?
> [EMAIL PROTECTED] seems to be a black hole.  You'll need to find
> someone willing to communicate with access to the buildd queues before
> the porters can do anything.

I said that deciding which packages should belong in P-a-s is porter work;
as is filing bugs on failed packages that shouldn't, providing patches, and
doing porter NMUs if necessary.

If the porters do this effectively, there's really not much need at all for
telling the buildd maintainers about transient build failures, because
they'll be pretty obvious (and account for the majority of failures, as it
should be).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

New postgrey Debian package uploaded - please test

[Adrian von Bidder]

Hi,

(postgrey mailing list: this is totally irrelevant if you're not using 
Debian.)

I've just uploaded a new version of the postgrey Debian package - 1.23-2 
(really *just* uploaded it.  You can get it from 
 until it appears in unstable.)

postgrey 1.23 has already been uploaded (Debian package version 1.23-1), but 
I've now changed quite a few things in the packaging, so I'd be happy if 
some people would test this package:

   * remove migration of upstream default installation to Debian package
 installation: postgrey has now been in Debian for some time.  This
 gets rid of all debconf stuff.
   * use dpkg-statoverride instead of directly calling chmod/chown
   * create group postgrey instead of using nogroup (closes: #277551)

thanks & greetings
-- vbi

-- 
If you're going to America, bring your own food.
-- Fran Lebowitz, "Social Studies"


pgpPzaXqMDwoe.pgp
Description: PGP signature

Re: StrongARM tactics

[Steve Langasek]

On Tue, Dec 06, 2005 at 02:33:34PM +0100, Thiemo Seufer wrote:
> Steve Langasek wrote:
> [snip]
> > > -grub2: !hppa !ia64 m68k# 
> > > bootloader
> > > +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc # 
> > > bootloader for i386/powerpc [?]

> Is a P-a-s entry some sort of a final verdict?

No, but it's a fairly long-term one; when people are concerned about
response time of the folks managing P-a-s, increasing churn certainly isn't
advisable, and having a package in P-a-s that shouldn't be has much more of
an impact than not having one listed that should be. :)

> I don't think it makes sense to attempt builds of a package for some years
> when it is known to fail. (Years might not be true for grub2, an example
> which comes to mind is gwydion-dylan.)

Agreed.  I think grub2 is a bit different, because upstream is (AIUI)
explicitly working on porting it to other architectures, so it bears
checking with the porters first.

> [snip]
> > > +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386   # 
> > > reads ROM from /dev/mem, i386/amd64/ia64-specific

> > The description says this package "can also extract font data from video
> > card ROMs."  Are we certain this is specific to i386/amd64/ia64?

> At least for mips/mipsel reading /dev/mem with a PC-like hardcoded
> offset won't yield anything useful.

Sure; but the root of this thread is a post talking about arm boards with
VGA BIOS emulation, so... :)  Again, worth checking with porters on.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: postinst scripts failing because a new conffile wasn'taccepted: Is it a bug?

[Dominique Dumont]

> My proposal to avoid such problem is to implement multilevel
> configuration, where the package default configuration and the local
> overrides are stored in separate files, making sure local
> configuration do not affect changes to the package default, and thus
> no question is asked during upgrade.

I have a tool that:
- is able to read the local configuration file
- fill any blank with default values provided by the packages
- re-write local file with user's values and enw default values.

The only hitch is that reading and writing file may be tricky since
the syntax of configuration files varies widly from one package to
another.

Would this kind of tool interest you ? 

Cheers

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Anthony Towns]

On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
> I can do the analyzing, but what should I do with the results?

Put them on a webpage so anyone can see them, and if you don't find
someone who'll give you an immediate response, track the issues over
time so you can trivially demonstrate how big a benefit there would be
if people would start paying attention.

If you're using the BTS (by filing, analysing or fixing FTBFS bugs, eg),
tracking the bugs with a usertag might be convenient and useful.

(I don't know what the actual/perceived problem here is to give more
detailed suggestions, sorry)

Cheers,
aj



signature.asc
Description: Digital signature

Bug#342366: ITP: postgresql-filedump -- Utility to format PostgreSQL files

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes <[EMAIL PROTECTED]>

* Package name: postgresql-filedump
  Version : 8.1
  Upstream Author : Patrick Macdonald <[EMAIL PROTECTED]>
* URL : http://sources.redhat.com/rhdb/
* License : GPL
  Description : Utility to format PostgreSQL files

This package contains a utility to format PostgreSQL heap/index/control
files into a human-readable form. You can format/dump the files several
ways.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-rc4-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Daniel Ruoso]

Hi,

I'll try to move forward in the direction of a more consensual proposal
about the declassification. 

In this discussion, two points were made clear to me:

1) It would be really nice to have the d-p archives available to those
who want to understand better how debian works, and from this
perspective, the selection of which content will be made available is
not a desirable thing.

2) On the other hand, some sensitive material should not be indexed by
google, nor be available without any criteria. This is certainly the
point that is raising most of the disagreement.

So, my conclusion is that it would be nice to have two types of
publications:

1) Selected Readers
2) Selected Content

The first type of publication could embrace the entire content of
debian-private, but restrictions will be applied for those who want to
read, basically, the need of identification of the reader and the
agreement to a NDA on the same terms applied to every debian developer
about the privacy of the mailing list.

The second type would be open to the public in general, and then could
be strictly opt-in, since this would be indexable by google, and it's
desirable that the authors have a choice on that.

This way, I'd like to formalize a new Proposal.

--

In accordance with principles of openness and transparency, Debian
will seek to declassify and publish posts of historical or ongoing
significance made to the Debian Private Mailing List.

This publication will be made in two different ways, both managed by a
declassification team assigned by the Debian Project Leader:

1) 3 or more years old posts will be made available on a public site,
but the access to this content will be regulated by the following
constraints:
  * The declassification team will ellaborate a NDA in the same terms
of the policy applied to every Debian Developer concerning the 
privacy of the mailing list.
  * The prospective reader will have to identify himself to the  
declassification team, and will need to have a GPG key signed 
by a Debian Developer.
  * The prospective reader will have to send a GPG signed email in
which he will agree to the NDA.
  * The declassification team will send username, password and the url 
in a GPG sined and cyphered email to the prospective reader.
  * The access logs of this content will be kept.
2) 3 or more years old posts will be made available on a public site
with public anonymous access according to the following constraints:
  * The declassification team will request approval for publication of
the posts to its authors, which can request:
a) to keep the entire post private,
b) to remove his identification from the post,
c) to remove certain parts of the post,
d) to publish the post as it is.
  * If an author requests that some post or some parts of it needs to 
be kept private, the references to it will be removed from other 
posts.
  * If the author doesn't reply to the request for publication, the 
entire post will be kept private.
  * If the post already contains a "you're allowed to quote me outside
debian-private"-like statement, the declassification team will not 
need to contact the author, and the post will be published.

---

I hope this is closer to a consensus...

daniel


signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: StrongARM tactics

[Aaron M. Ucko]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> +pcsx: i386# i386 
> assembly

AFAICT, this is only because its Linux/Makefile forces CPU to ix86
unconditionally.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342466: ITP: rcairo -- Cairo bindings for the Ruby language

[Thierry Reding]

Package: wnpp
Owner: Thierry Reding <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: rcairo
  Version : 1.0.0
  Upstream Author : Evan Marin, Øyvind Kolås, MenTaLguY, Kouhei Sutou
* URL : http://cairographics.org/rcairo
* License : GPL
  Description : Cairo bindings for the Ruby language

Cairo is a multi-platform library providing anti-aliased vector-based
rendering for multiple target backends. This package contains libraries for
using Cairo with the Ruby programming language. It is most likely useful in
conjunction with Ruby bindings for other libraries such as GTK+.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-fglrx-alsa
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)



signature.asc
Description: Digital signature

Re: StrongARM tactics

[Ryan Schultz]

On Tuesday 06 December 2005 05:51 am, Thomas Viehmann wrote:
>+%libopenspc: i386 kfreebsd-i386  
# i386 assembler
>+%xmms-openspc: i386 kfreebsd-i386# i386 
dependency (libopenspc)
>+pcsx: i386  # i386 
assembly

I've tried to contact the maintainers (listed in the file) of the 
packages-arch-specific file for two of my packages in your patch, 
xmms-openspc and libopenspc, and have never received a response -- my sponsor 
said that the maints were very busy, so I've not mailed them since. Neither 
of these packages are going to work on non-i386 in the future, so certainly 
feel free to add them!

I'm also the maintainer of PCSX and its associated plugins, which will all 
likely go Arch: i386 in my sponsor's next upload of them. They *might* all 
build on other arches, but whether they will *work* is questionable. PCSX has 
terrifying code (to me), and I'm not sure which C routines dropping the ASM 
would reactivate, which could cause it to have even more random segfaults -- 
I have most of those on i386 fixed, but I can't test on other arches. Having 
said that, I'd prefer that it not be added to p-a-s yet, because I intend to 
somehow ensure that it works on other arches soon, and then I'll redo the 
Arch line.

Summary: please add xmms-openspc and libopenspc, but not yet pcsx or psemu-*, 
if you can.

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [kde-edu]: Sugg: Framework for Science Meters

[RalfGesellensetter]

Dear list, 

I would be delighted if anybody might contribute to this topic:

who knows of existing projects evaluating measurement deviced connected 
to serial ports (chemistry, physics)..? Free software that is...

--  forwarded  --

Subject: Re: [kde-edu]: Sugg: Framework for Science Meters
Date: Mittwoch 07 Dezember 2005 09:24
From: Karl Sarnow <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Excellent idea. I would like to promote the development of an
 OpenSource laboratory at Xplora.

We have some partner working on Webexperiments. Please have a look at
our webpages.

Brining in their experience might be useful.

 From my point of view, the OpenSource laboratory should focus on
Hardware interfacing to the USB port and Software taking signals from
there.

I am sure that thre is a lot of softrware existing. Having an overview
would be nice.

Thanks for the initiative.

Karl

RalfGesellensetter wrote:
>Dear list,
>
>during "Linuxtage Essen" (Essen Linuxdays), some scientists addressed
>the lack of free interfaces to scientific gear such as thermometers,
>gyrometers, geigercounters, whatsoever.
>
>As a matter of fact, there are already loads of measuring tools - but
> it lacks integration and usabilities if we want to use them in
> school.
>
>This made me think: How about a framing project / application similar
> to ksensors? Existing implementations could dock into such framework.
> The framework itself could provide features like
>- data recording
>- data plotting
>- statistical evaluations.
>
>Also popping into my mind is ksimus datarecorder as one possible
>frontend. As it comes to realtime data, acoustic recorders could be
>another approach.
>
>What is your comments on this? Should we forward this idea to
> kde-devel?
>
>Cheers & merry nick day ;)
>
>Regards
>Ralf
>___
>kde-edu mailing list
>[EMAIL PROTECTED]
>https://mail.kde.org/mailman/listinfo/kde-edu

--
Karl Sarnow
Pedagogical Advisor
Xplora - The European Science Education Gateway
E-mail: [EMAIL PROTECTED]

Rue de Treves 61
B-1020 Brussels
Belgium
Tel.: +32.2.790.7578
Fax.: +32.2.790.7585

Visit us at
EUN: http://www.eun.org
Xplora: http://www.xplora.org

___
kde-edu mailing list
[EMAIL PROTECTED]
https://mail.kde.org/mailman/listinfo/kde-edu

---


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[mjr]

Daniel Ruoso:
> I'll try to move forward in the direction of a more consensual proposal
> about the declassification.=20
> 
> In this discussion, two points were made clear to me:

You do not mention the copyright and ethical problems,
but the proposal seems to address them, near enough.
Is the OP willing to accept it, or need we gather seconds?

Thanks,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Gaudenz Steinlin]

On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> So, my conclusion is that it would be nice to have two types of
> publications:
> 
> 1) Selected Readers
> 2) Selected Content
> 
> The first type of publication could embrace the entire content of
> debian-private, but restrictions will be applied for those who want to
> read, basically, the need of identification of the reader and the
> agreement to a NDA on the same terms applied to every debian developer
> about the privacy of the mailing list.
> 

One of the main goals of the original GR was to make the archives
available for research. How will you be able to publish the results 
of such research if you agreed to an NDA. One of the main principles
of scientific research is to make your results reproducible by others.  
This is impossible if you base your research on data which is only
available under an NDA.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpRuLRQrVJO3.pgp
Description: PGP signature

Re: StrongARM tactics

[Bill Allombert]

On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote:
> Saying "that's the buildd admin's job" about tasks that don't *need* to be
> done by the buildd admin is a pretty effective way of encouraging the
> problems that the Vancouver proposal sought to address, where two or three
> people end up carrying all the ports, and all their time is eaten up by
> maintaining the buildds and giving back failed packages with no time for
> following through on the permanent failures (which, even though they
> sometimes represent a minority of Maybe-Failed packages usually account for
> a majority of the actual work needing done).

This go against the two basic rules for a volunteer organisation.

1) Volunteers doing the job should be people interested in doing it.
2) Responsibility should go to people that are going to do the job.

Which translates here to:
1) Buildd admin should be people interested in supporting the port.
2) People that are going to support the port must get the responsibility.

Making "buildd admin" a purely administrative task while porters are
not even trusted to do a binary upload is not going to work because you
will never find volunteers accepting to work under theses terms.
If the Vancouver proposal is the constatation that the old model did not
work the solution is to change the model, not to expect that people will
suddenly accept it. Unless you are just looking at an excuse to remove 
ports, obviously. Fortunately there are no external organisations forcing
the old model upon us, so there is no reason not to change it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.

Whoever decided to make elvis the default editor on master is not color-blind.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs loginfo configuration for alioth?

[Junichi Uekawa]

Hi,

> > > I'm looking for a 'loginfo' file configuration that works 
> > > for alioth.
> > > I thought I have found a solution few days ago, but when 
> > > I came back, it no longer seems to work correctly:
> > > 
> 
> The script used in debian-gis repo (pkg-grass) works like a charm. 
> Feel free to use it... I also looked around a bit to have a working program
> after alioth upgrade.

Thanks for the info.
I see there's a log_accum.pl.

Am I right in thinking that system-provided cvs-mailcommit doesn't 
work in any way at all?
That's a bit of a nuisance.



As for %1{sVv}, I think I've been trying %l{sVv} all the time...
Yikes.

However, changing that to '%1{sVv}' does not seem to really work.

$ cvs ci -m 'update TODO' TODO
/cvsroot/pbuilder/pbuilder/debian/TODO,v  <--  TODO
new revision: 1.51; previous revision: 1.50
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Unknown argument 'pbuilder/debian TODO,1.50,1.51', deleting.


regards,
junichi

-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Wouter Verhelst]

On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> Hi,
> 
> I'll try to move forward in the direction of a more consensual proposal
> about the declassification. 
> 
> In this discussion, two points were made clear to me:
> 
> 1) It would be really nice to have the d-p archives available to those
> who want to understand better how debian works, and from this
> perspective, the selection of which content will be made available is
> not a desirable thing.
> 
> 2) On the other hand, some sensitive material should not be indexed by
> google, nor be available without any criteria. This is certainly the
> point that is raising most of the disagreement.
> 
> So, my conclusion is that it would be nice to have two types of
> publications:
> 
> 1) Selected Readers
> 2) Selected Content
> 
> The first type of publication could embrace the entire content of
> debian-private, but restrictions will be applied for those who want to
> read, basically, the need of identification of the reader and the
> agreement to a NDA on the same terms applied to every debian developer
> about the privacy of the mailing list.
> 
> The second type would be open to the public in general, and then could
> be strictly opt-in, since this would be indexable by google, and it's
> desirable that the authors have a choice on that.
> 
> This way, I'd like to formalize a new Proposal.
> 
> --
> 
> In accordance with principles of openness and transparency, Debian
> will seek to declassify and publish posts of historical or ongoing
> significance made to the Debian Private Mailing List.
[...]
> I hope this is closer to a consensus...

Afraid not. This proposal basically creates a second class of people --
those who we want to sign NDA's to be able to read stuff.

That's even further away from 'openness and transparency' than the
status quo. The idea that developers sometimes have private things
to say is at least defendable; the idea that Debian is joining the NDA
crap is not, IMNSHO.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Manoj Srivastava]

On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns  said: 

> On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
>> I can do the analyzing, but what should I do with the results?

> Put them on a webpage so anyone can see them, and if you don't find
> someone who'll give you an immediate response, track the issues over
> time so you can trivially demonstrate how big a benefit there would
> be if people would start paying attention.

Is it just me, or does it seem entirely one sided and
 thankless effort, where one goes off and  does a boatload of work,
 and petritions for the powers on high to maybe deign to notice all
 the diligence being put in? This kind of thing can rapidly suck the
 fun out of most things.

manoj
-- 
Support Mental Health.  Or I'll kill you.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Bushnell BSG]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns  
> said: 
>
>> On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
>>> I can do the analyzing, but what should I do with the results?
>
>> Put them on a webpage so anyone can see them, and if you don't find
>> someone who'll give you an immediate response, track the issues over
>> time so you can trivially demonstrate how big a benefit there would
>> be if people would start paying attention.
>
> Is it just me, or does it seem entirely one sided and
>  thankless effort, where one goes off and  does a boatload of work,
>  and petritions for the powers on high to maybe deign to notice all
>  the diligence being put in? This kind of thing can rapidly suck the
>  fun out of most things.

It's not just you.

I think we need some kind of performance review for key "only one
person can do it" jobs in Debian, so that we can evaluate the
performance of those tasks, and then recruit new volunteers to take
them over if the project as a whole is dissatisfied with the
performance of them.

We already have mechanisms to do this for package maintenance; now
it's time to have mechanisms for other jobs too.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Anthony Towns]

On Wed, Dec 07, 2005 at 07:51:20PM -0600, Manoj Srivastava wrote:
> On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns  
> said: 
> > On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
> >> I can do the analyzing, but what should I do with the results?
> > Put them on a webpage so anyone can see them, and if you don't find
> > someone who'll give you an immediate response, track the issues over
> > time so you can trivially demonstrate how big a benefit there would
> > be if people would start paying attention.
> Is it just me, or does it seem entirely one sided and
>  thankless effort, where one goes off and  does a boatload of work,
>  and petritions for the powers on high to maybe deign to notice all
>  the diligence being put in? 

*shrug* I doubt it's just you; I only suggest it because it's worked for
me in the past -- for britney, for the BTS CGIs, for archiving old bugs
for the BTS, possibly some others.

> This kind of thing can rapidly suck the fun out of most things.

Yeah, well, there's all sorts of ways of sucking the fun out of things.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#342504: ITP: libjgrapht-java -- mathematical graph theory library for Java

[Charles Fry]

Package: wnpp
Severity: wishlist
Owner: Charles Fry <[EMAIL PROTECTED]>


* Package name: libjgrapht-java
  Version : 0.6.0
  Upstream Author : Barak Naveh <[EMAIL PROTECTED]>
* URL : http://jgrapht.sourceforge.net/
* License : LGPL
  Description : mathematical graph theory library for Java

 JGraphT is a free Java graph library that provides mathematical
 graph theory objects and algorithms. JGraphT supports various types of
 graphs including:
  - directed and undirected graphs
  - graphs with weighted, unweighted, labeled or user-defined edges
  - various edge multiplicity options, including simple graphs,
multigraphs and pseudographs
  - unmodifiable graphs: allow modules to provide "read-only" access
to internal graphs
  - listenable graphs: allow external listeners to track modification
events
  - subgraphs: graphs that are auto-updating subgraph views on other
graphs
 .
 Graphs can be visualized using the JGraph library.
 .
  Homepage: http://jgrapht.sourceforge.net/

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Symantec AntiVirus/Filtering for Domino detected a virus in a document you authored.

[OA_SVR/logistics%LOGISTICS]

Please contact your system administrator.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Robert Collins]

On Thu, 2005-12-08 at 00:08 +0100, Gaudenz Steinlin wrote:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> > So, my conclusion is that it would be nice to have two types of
> > publications:
> > 
> > 1) Selected Readers
> > 2) Selected Content
> > 
> > The first type of publication could embrace the entire content of
> > debian-private, but restrictions will be applied for those who want to
> > read, basically, the need of identification of the reader and the
> > agreement to a NDA on the same terms applied to every debian developer
> > about the privacy of the mailing list.
> > 
> 
> One of the main goals of the original GR was to make the archives
> available for research. How will you be able to publish the results 
> of such research if you agreed to an NDA. One of the main principles
> of scientific research is to make your results reproducible by others.  
> This is impossible if you base your research on data which is only
> available under an NDA.

Its quite possible to publish research conducted under an NDA without
compromising that NDA: but one is constrained in the quotes and
disclosure you can make.

As for being reproducible by others, the suggested process for getting
access seems to be so trivial any researcher with access to the internet
will be able to complete it fairly easily. It also is not under onerous
terms (such as MS's kerberos extensions were) so entering into the NDA
should not limit or pose an unreasonable burden on anyone.

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Lionel Elie Mamane]

On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:

>> I'll try to move forward in the direction of a more consensual proposal
>> about the declassification. 

>> So, my conclusion is that it would be nice to have two types of
>> publications:

>> 1) Selected Readers
>> 2) Selected Content

>> The first type of publication could embrace the entire content of
>> debian-private, but restrictions will be applied for those who want
>> to read, basically, the need of identification of the reader and
>> the agreement to a NDA on the same terms applied to every debian
>> developer about the privacy of the mailing list.

Well, if we let anybody read it, it has absolutely no point asking for
an NDA. Your proposal says that anybody can get read it, if he signs
an NDA. This procedure could be a useful tool if we restricted it to,
say, people like Biella Coleman that have a "real use", sanctioned by
Debian and all, out of the_whole_ archive. (This should not keep us
from opening up nearly everything else.)

>> I hope this is closer to a consensus...

> Afraid not. This proposal basically creates a second class of people
> -- those who we want to sign NDA's to be able to read stuff.

> That's even further away from 'openness and transparency' than the
> status quo. The idea that developers sometimes have private things
> to say is at least defendable; the idea that Debian is joining the
> NDA crap is not, IMNSHO.

NDA's have a bad reputation in our community; sometimes they make
sense. They are just a formal version of "yes, I understand the
information I get is confidential; I will treat it as such". I think
it makes sense for very selected readers that have a good use of the
whole archive. It is indeed a bit silly if anyone can just sign it and
get access.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]