Re: Forwarding bugs upstream

[Andrei Popescu]

On Mi, 12 ian 11, 10:55:34, Paul Wise wrote:
> On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson  wrote:
> 
> > Which upstream bug trackers, if any, would make the above not work?
> 
> Sourceforge and probably Gforge/FusionForge trackers.
> 
> The only tracker I'm aware of which would work is Trac, some instances
> of which allow anyone to put in anyone else's email address as the
> author of the bug.

Would it be possible to subscribe the Debian bug instead and have the 
upstream tracker accept mail from the BTS?

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Josselin Mouette]

Le mardi 11 janvier 2011 à 23:54 +, brian m. carlson a écrit : 
> I've noticed a trend lately that I am often asked to forward the bugs I
> report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script.  I believe, and I continue to believe,
> that maintainers should forward bugs upstream instead of requiring (or
> strongly encouraging) users to do so.

As soon as there are enough maintainers to do that, yes, that makes
sense. Since for most large packages there are not, we are forced to do
what we can.

Skilled maintainers already spend way too much time only reading the
flow of bug reports. That’s time not spent into packaging work and
long-term improvement. We regularly ask newcomers to try and deal with
bugs, but this boring and daunting task only serves to discourage them.

Given that only a rough tenth of the bugs are actually useful, that’s
the amount that can be either forwarded as is (knowing that the upstream
maintainer will not ask for details the maintainer doesn’t have) or
dealt with directly. If someone finds a way to reduce the noise, maybe
what you suggest could become feasible.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1294821223.25195.68.ca...@meh

Re: Forwarding bugs upstream

[Antonin Kral]

* Drake Wilson  [2011-01-12 08:09] wrote:
> Quoth Paul Wise , on 2011-01-12 10:55:34 +0800:
> [among other responses]
> > Sourceforge and probably Gforge/FusionForge trackers.
> > 
> > The only tracker I'm aware of which would work is Trac, some instances
> > of which allow anyone to put in anyone else's email address as the
> > author of the bug.
> 
> So basically "most or all of them", then.  Right.
> 
> This doesn't leave much in the way of good options:

What about handling this on Debian side? So the maintainer will not
register his/her personal account to upstream but package specific email
alias. If email is received then BTS
  - will add it into the bugreport if pairing information is found (e.g.
upstream ticket ID)
  - will forward to maintainer otherwise

  Antonin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112075111.ga3...@bobek.cz

Re: Forwarding bugs upstream

[Roland Mas]

Drake Wilson, 2011-01-11 20:19:34 -0700 :

[...]
> This doesn't leave much in the way of good options:
>
>   - Having the user report bugs twice
[...]
>   - Having the maintainer be the reporter of record for upstream
[...]
>   - Having the maintainer forward the bug report but make the user the
> reporter

In a mid-term future, there's another possibility.  Forges and bug
trackers have started thinking about, and implementing, infrastructure
to allow distributed bug tracking.  There are at least two efforts in
that direction:

- the “SD” approach, where people have one local interface that talks to
  possibly several remote trackers and syncs stuff around; SD already
  has bridges to several engines.

- the “OSLC-CM” approach, where trackers implement a common API
  allowing creation and manipulation of reports with a
  machine-to-machine interface; this allows a single interface (think
  dashboard) to display and interact with bugs independently of their
  physical location.

If one or the other approach ends up generally usable, then a new
scenario emerges:

- end-user reports bug on the Debian BTS (or the Fedora Bugzilla, or the
  Ubuntu Launchpad, or whatever it is Suse has);

- distro maintainer does some tagging if they consider the bug to be
  upstream;

- upstream has a handful of accounts on the distros' BTS, and they see
  the appropriately tagged bugs on their dashboard; they can interact
  with the user from there, and possibly clone the bug into their own
  local BTS.

  We still face a scalability problem, in that upstreams may need an
account on each of the (major) distributions' BTS that require logins,
but in the end both upstream and the end user can work on the same
report.  Whether that report is only on the distro's BTS or synced with
upstream's BTS is something that time will tell.

  For reference, the OSLC-CM API is currently being implemented for
FusionForge, and I'm told Mantis already has it.  I seem to recall work
was in progress for Bugzilla too, but I don't remember the details.  On
the GUI client side, work is happening in Eclipse and probably others.

Roland.
-- 
Roland Mas

Indépendant en informatique libre -- Free software freelance
http://www.gnurandal.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/8739oywkdx@mirexpress.internal.placard.fr.eu.org

Re: debconf translations broken in multiple packages

[Jonathan Wiltshire]

On Wed, Jan 12, 2011 at 07:53:09AM +0100, Christian PERRIER wrote:
> > Many of these packages errors are direct or indirect consequences of
> > my l10n work during the lenny-squeeze release cycle.
> > 
> > Direct when the last uploaded version is an NMU of mine..
> > 
> > Indirect when a maintainer uploaded after I prodded him|her and sent a
> > patch
> > 
> > Would it be OK for the release team if packages fixing these encoding
> > errors are uploaded? I may try to at least correct some of them (those
> > I NMU'ed).

Likewise, I spotted two packages in that list that I co-ordinated reviews
for, so I'm happy to fix up any errors that have crept in - Christian,
please ping me if you need anything.



-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Bug#609772: ITP: osmpbf -- Java access library for OpenStreetMap PBF file format

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: osmpbf
Version: 1.1
Upstream Author: Scott A. Crosby. 
URL: http://github.com/scrosby/OSM-binary
License: LGPL-3+
Description: Java access library for OpenStreetMap PBF file format
 Osmpbf is a Java library to read and write OpenStreetMap PBF files.
 PBF (Protocol buffer Binary Format) is the new file format to describe
 OpenStreetMap data, intended to replace the old XML-based one. The PBF
 format uses Google Protocol Buffers as low-level storage.

This package is a dependency of the new version of osmosis, see #605698.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org



signature.asc
Description: OpenPGP digital signature

Re: Forwarding bugs upstream

[Sune Vuorela]

On 2011-01-11, brian m. carlson  wrote:
> I've noticed a trend lately that I am often asked to forward the bugs I
> report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script.  I believe, and I continue to believe,

I have considered to take this one step further. Close bugs reported in
Debian BTS with a severity of important or less that is a bug that
should primarily be fixed upstream.

Currently, the debian Qt/KDE team has around 800 open, non-forwarded
bugs reported against their packages. I would guess that maybe 20 of
them is packaging issues. But we can't find them. 
The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is
pure upstream issues. 

/Sune
 - who also don't think that being a manual email2webformandback proxy
   is a good idea.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniirb1r.rvp.nos...@sshway.ssh.pusling.com

Re: [vu...@gnome.org: Cross-distro meeting about application installer]

[David Kalnischkies]

(re-adding debian-project@ to the loop so both lists have the attendees info)

On Fri, Jan 7, 2011 at 10:33, Stefano Zacchiroli  wrote:
> On Thu, Dec 30, 2010 at 11:58:05AM +0100, Stefano Zacchiroli wrote:
>> We're organizing a cross-distro meeting in January to discuss the
>> "application installer" topic. It's a hot topic in many distros at the
>> moment, and we believe it's an area where we can collaborate a lot.
[…]
>> All the information about the meeting is at
>> http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011
>
> Status update on Debian presence there: Enrico Zini has kindly
> volunteered to attend as a Debian representative. I'd like to took this

Another short update: I volunteered last-minute as a second
debian attendee to get the 'platform' APT into the loop, too.

Together with our friends from ubuntu we should have a broad coverage and
voice for debian in the meeting and a lot to discuss but feel free to
provide (additional) topics and opinions for us to bring along to ensure
they will be all covered.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=l-obcc75dtyzc3opx6ln_rmt=kx2bbjeg6...@mail.gmail.com

Bug#609791: ITP: light-themes -- Radiance and Ambiance themes for GNOME desktop

[Adnan Hodzic]

Package: wnpp
Severity: wishlist
Owner: Adnan Hodzic 



* Package name: light-themes
  Version : 0.1.8.4
  Upstream Author : Ubuntu Artwork Team 
* URL : https://launchpad.net/light-themes
* License : (CCPL)
  Programming Lang: 
  Description : Radiance and Ambiance themes for GNOME desktop

This package contains Radiance and Ambiance themes for GNOME 2.x desktop and it 
consists of Metacity and GTK+ murrine engine. This theme is a default one use 
in Ubuntu.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112143707.11152.15158.report...@havoc

Re: Forwarding bugs upstream

[brian m. carlson]

On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote:
> I think it is perfectly fine for a user to submit a bug report to
> the Debian BTS first.  They may not always be equipped to know what
> is a Debian and what is an upstream bug.  And I also think it ought
> to be perfectly valid for the Debian developer to close the bug
> saying it's an upstream issue, together with a pointer to the
> upstream BTS and promise to get involved should there be any
> question about the Debian packaging, environment, etc.

I think this can actually increase the maintainer's burden, since it can
increase the number of duplicate bug reports, since there isn't already
a bug listed as reported.  I generally assume that if a bug is open but
not marked forwarded that it isn't forwarded, and I'm not intrinsically
opposed to this.  Forwarded bugs are better, but if it doesn't happen
immediately, that's okay.

> Now, here's how it proceeds if I have to forward a bug upstream for
> Bacula, which uses Mantis.  Creating a Mantis account takes 30
> seconds, but Mantis won't email reports to people without accounts,
> and the only way to add stuff to it is on the web.

As I've said, I generally don't mind being added to the CC list, and I
think that BTS systems should allow non-subscribers (and subscribers) to
add information via email.  I realize that upstreams tend to use BTSes
that don't do that and therefore make their end users go through a lot
of unnecessary pain.  Also, if the BTS won't CC me when someone responds
to the bug (even with an account), there is zero chance of me reporting
the bug upstream, since I have better things to do with my life than
constantly checking a slew of BTSes.

> I'm adding zero value here.  Zero.  It is a huge and frustrating
> waste of my time.  It is also frustrating for upstream, who would
> rather just talk with the user directly and involve me if they think
> there's a Debian-specific question.  I don't understand why some
> users want it to go this way, but many clearly do despite the fact
> that they get worse service.

I think it depends on the situation.  I've looked at the open and
forwarded bugs reported under this email address and of the 60, there
are at least 47 that I could immediately determine (just by being
reminded of the Subject line) that included a testcase or a patch or
were trivially easy to reproduce (or understand wrt the desired feature
for wishlist requests).  Those are pretty much forward-and-forget.

There are cases where the maintainer cannot appreciably reproduce the
problem (such as with the kernel or X) and then I have to make a
decision whether I want to put up with the bug or forward it upstream
myself.  In these cases, it's usually the former, since I am just not
going to recompile my kernel (which is the Debian one) the ten times
required to bisect the problem.  If there's a new version in
experimental, I will often try that to see if it solves the problem,
though, and report back.

I try to forward bugs upstream when I have the time, especially when I
have a patch, since it may need tweaking with upstream.  But I always
try to put a patch in the Debian BTS, since it is much more likely to be
rapidly fixed in that case.  (#605941 is a great example of this.)

So I think what my position is is this: if the bug is simple, clear, and
easily understandable, then I don't think it's unreasonable for the
maintainer to forward the bug upstream.  Examples that I think fit into
this category:

* (normal) This program produces out-of-range results when I use the
  attached file as input and option -p.
* (wishlist) This program should support W3C specification ABC (as well
  as the currently-supported DEF) with regard to XYZ functionality. 

If it's going to be difficult and require the user and upstream to work
together to solve the problem, then it's okay to say something like, "I
can't reproduce this problem and upstream is not going to be able to fix
it without your help, so would you mind forwarding the bug upstream?"
Giving a reason actually makes me much more likely to comply and less
likely to be irritated.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Gunnar Wolf]

Ben Finney dijo [Wed, Jan 12, 2011 at 04:01:46PM +1100]:
> (...)
> > I'm adding zero value here. Zero. It is a huge and frustrating waste
> > of my time.
> 
> Not in my view. I appreciate the Debian package maintainer acting in the
> interest of “lower the barrier for each Debian user of this package to
> report useful bug information”.
> 
> To be clear: Thank you for the time you spend doing this, and the same
> to any other Debian maintainer who does unromantic work to keep the
> good information flowing.

You are clearly adding value, you will probably word the user's
request in a better way, you will know the library versions and
settings the package was compiled with, the way it is installed,
etc. You will probably forward only some relevant bits - We as package
maintainers should bridge between a nontechnical user and the upstream
developers. Of course, if your bug report was initially submitted by a
technically knowledgeable user, it might be better just to point him
to a bug report (already opened by you) in the upstream tracker. Also,
when I forward a bug report, I quote the Debian BTS address for the
upstream developers to be able to get the original (although I will
mediate anyway).

Of course, there is not just one kind of user or upstream. Some will
appreciate to get more involved. Some users will sadly just say "this
is b0rken, you must fix it, you suck" - But they are IMO not
prevalent. Many upstreams will want users to use the latest versions,
and it is our task to find how to fix/backport.

> Quite the opposite, from my position. A great feature of the Debian BTS
> is that any user can interact with it through a standard interface
> without maintaining multiple separate identities; heck, without having
> to create a single new identity at all.

FWIW, I have been asked by users and upstreams whether they can
interact with bug reports via a simpler interface, as they prefer not
to use mail for it. Of course, it all depends on the person at hand. I
agree it is good to have a unified, standarized interface for our
users. And, of course, our BTS serves us (the Debian community) very
well.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112153516.ga26...@gwolf.org

ITP: facturlinex2 -- Billing application, storage and sale POS

[Nicolás López de Lerma Aymerich]

Package: facturinex2
Severity: wishlist
Owner: Nicolas Lopez de Lerma Aymerich 

* Package name : facturlinex2debian-de...@lists.debian.org
  Version : 2.0.0
  Upstream Author : Nicolas Lopez de Lerma Aymerich

* URL : http://facturlinex.sourceforge.net/

* License : GPL
  Description: Billing application, storage an sale POS


  Billing application, storage and sale POS, multi-shop,
  multiuser, streamlines the process when making sales,
  invoice, orders or request statistics, reducing waiting time,
  improving the treatmet and competitive efficiency of the company.


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

Re: Forwarding bugs upstream

[Ian Jackson]

John Goerzen writes ("Re: Forwarding bugs upstream"):
> I'm going to have a slightly different viewpoint on this.

I agree with John, basically.

> I'm adding zero value here.  Zero.  [...]

Some people have replied suggesting scenarios where the Debian
maintainer is adding something.  That's fine - in that case, the
maintainer can do whatever is necessary to add that value.

But I think this should be up to the Debian maintainer.  Being a
Debian maintainer should not mean agreeing to be a helpdesk or bug
proxy.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19757.56337.388114.637...@chiark.greenend.org.uk

Re: Forwarding bugs upstream

[Ian Jackson]

brian m. carlson writes ("Re: Forwarding bugs upstream"):
> On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote:
> > I think it is perfectly fine for a user to submit a bug report to
> > the Debian BTS first.  They may not always be equipped to know what
> > is a Debian and what is an upstream bug.  And I also think it ought
> > to be perfectly valid for the Debian developer to close the bug
> > saying it's an upstream issue, together with a pointer to the
> > upstream BTS and promise to get involved should there be any
> > question about the Debian packaging, environment, etc.
> 
> I think this can actually increase the maintainer's burden, since it can
> increase the number of duplicate bug reports, [...]

If the maintainer agrees with you then they will be happy to deal with
the bug report the way you want.  But I think this should be up to the
maintainer to decide.

> As I've said, I generally don't mind being added to the CC list, and I
> think that BTS systems should allow non-subscribers (and subscribers) to
> add information via email.  I realize that upstreams tend to use BTSes
> that don't do that and therefore make their end users go through a lot
> of unnecessary pain.  Also, if the BTS won't CC me when someone responds
> to the bug (even with an account), there is zero chance of me reporting
> the bug upstream, since I have better things to do with my life than
> constantly checking a slew of BTSes.

That is up to you.  

If you report the bug to the Debian BTS but neither you nor the Debian
maintainer want to do the make-work of dealing with upstream's tedious
BTS, then the bug will sit in Debian's BTS tagged "should go upstream"
indefinitely.

I don't think it is up to you to say that this is the maintainer's
problem and that they must do something about it.  If it bothers you,
you should yourself do the work to improve matters.

> I think it depends on the situation.  I've looked at the open and
> forwarded bugs reported under this email address and of the 60, there
> are at least 47 that I could immediately determine (just by being
> reminded of the Subject line) that included a testcase or a patch or
> were trivially easy to reproduce (or understand wrt the desired feature
> for wishlist requests).  Those are pretty much forward-and-forget.

If you think the work of forwarding bugs upstream is so important and
useful - more important and useful than the work that you are
currently doing - then perhaps you would like to take on that role for
some existing maintainers who don't have the time, or who feel that it
isn't tha valuable ?

> So I think what my position is is this: if the bug is simple, clear, and
> easily understandable, then I don't think it's unreasonable for the
> maintainer to forward the bug upstream.  Examples that I think fit into
> this category:

I think it is always reasonable for the maintainer to forward the bug
upstream.  

But what I think is bad is _demanding_ or _requiring_ the maintainer
to forward the bug upstream.  If they don't want to do that for
whatever reason then asking the submitter to do so is IMO perfectly
acceptable.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19757.56664.836061.356...@chiark.greenend.org.uk

Re: Forwarding bugs upstream

[Ben Hutchings]

On Wed, Jan 12, 2011 at 02:56:35PM +, brian m. carlson wrote:
[...]
> Also, if the BTS won't CC me when someone responds
> to the bug (even with an account), there is zero chance of me reporting
> the bug upstream, since I have better things to do with my life than
> constantly checking a slew of BTSes.
[...]
 
The bts-link system takes care of polling for upstream bug status
updates for several common bug trackers.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112172550.gu3...@decadent.org.uk

Re: DEP5: CANDIDATE and ready for use in squeeze+1

[Lars Wirzenius]

On ma, 2011-01-10 at 10:56 +0100, Stefano Zacchiroli wrote:
> So, the only timeframe during which the problem can be experienced is
> from now to the solution of #609160. I wonder if it is really worth to
> address this issue properly---by changing either the intended usage of
> Format: or by adding a separate Format-Version: field. My take is that
> it is not worth, we can just rely on implementations to bail out on out
> of date debian/copyright instances. YMMV, of course.

Oh, please, not more fields... :)

If a distinct Format: URL is deemed necessary for the revisions from now
until integration into the debian-policy package, then let's have that.
I would rather avoid it, though, since then the examples need to be
updated every time, and I'm lazy.

(Once in debian-policy, the Format: URL will have a version number, so
the problem will be solved.)

I have no idea when the debian-policy integration will happen, but I
hope soon -- at least in terms of the number of revisions of DEP5 we
produce until then.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1294853308.6791.35.ca...@havelock.lan

"Mass" (non invasive) NMUs planned to fix debconf translations broken in multiple packages

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):

> I have ready NMUs for most of the affeted packages. I can upload them
> soon.

My plans are to upload before the end of the upcoming week-end an NMU
for each of the affected package(s).

I currently have: 

astk_1.8.0-1.2
bandwidthd_2.0.1+cvs20090917-4.1
ddclient_3.8.0-11.3
halevt_0.1.6.2-1.4
iog_1.03-3.5
elmerfem_5.5.0.svn.4499.dfsg-1.1
boxbackup_0.11~rc8~r2714-1.1
masqmail_0.2.27-1.2
mini-buildd_0.8.15+nmu1
moodle_1.9.9.dfsg2-2.1
nvidia-cg-toolkit_2.1.0017.deb1+nmu3
ocsinventory-agent_2:1.1.1-2.3
postgrey_1.32-6.1
rinputd_1.0.3-6.1
poker-network_1.7.7-3.2
slbackup-php_0.3-2.2
typo3-dummy_4.3.0-4.1
setserial_2.17-45.3
update-inetd_4.38+nmu1
xmail_1.27-1.1
vpb-driver_4.2.49-1.1

For each of these package, the NMU only includes a fixed
debian/po/.po file and the needed changelog entry.

Unblock requests will follow after the uploads. NMU diffs will be sent
as new bug reports against the offending packages (hooray for nmudiff).

Please yell *now* if you object to this process.

(other packages affected by this are very likely to be dealt with too)




signature.asc
Description: Digital signature

Bug#609819: ITP: drupal6-thm-nokia-mobile -- nokia_mobile themes for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-thm-nokia-mobile
  Version : 1.3
  Upstream Author : Andrea Trasatti (http://drupal.org/user/170041)
* URL : http://drupal.org/project/nokia_mobile
* License : GPL
  Programming Lang: PHP
  Description : nokia_mobile themes for Drupal 6

This a theme designed for a mobile experience, it provides different 
presentation layers to best serve basic devices and high-end smartphones.

 * Integrated detection of device families (low, mid and high end) 
   specific for Nokia, but supporting many popular devices such as 
   iPhone, Android-based and Palm Pre/Pixi

 * Show different theme features depending on browser capabilities 
   (use accordions to hide areas that are not used frequently, use of 
   shades and CSS to make the look nicer, more)
  
 * Tweaks for touch devices

 * Specific tweaks for some specific Nokia devices such as the N900



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112190404.10013.35480.report...@a88-114-154-20.elisa-laajakaista.fi

network-manager rant

[Anssi Kolehmainen]

Hi all,

I just updated packages (which upgraded network-manager to 0.8.1-6) and then
rebooted computer. I was greeted with a five minute wait while ntpd tried to
query dns which was broken since network-manager decided to start, ignore
bridge mappings, do dhcp on physical port of the bridge (which of course
breaks the bridge) and clearing out /etc/resolv.conf. Again.

There seems to be bugs filed for the relevant things so I won't bother
creating new tickets. I just hope you would make network-manager not break
things when system is in perfect working order :)

My workaround was to purge network-manager and I'm planning to fix this by
creating a package which Conflicts: network-manager. Maybe you could provide
this kind of package by default :)

-- 
Anssi Kolehmainen
anssi.kolehmai...@iki.fi
040-5085390


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112185830.gx18...@aketzu.net

Bug#609820: ITP: pyxnat -- interface to access neuroimaging data on XNAT servers

[NeuroDebian Team]

Package: wnpp
Severity: wishlist
Owner: NeuroDebian Team 


* Package name: pyxnat
  Version : 0.6.2
  Upstream Author : Yannick Schwartz 
* URL : http://packages.python.org/pyxnat
* License : BSD
  Programming Lang: Python
  Description : interface to access neuroimaging data on XNAT servers
 XNAT is an extensible database for neuroimaging data.  pyxnat is a
 Python library that relies on the REST API provided by the XNAT
 platform since its 1.4 version. The main objective of pyxnat is to
 ease communications with an XNAT server to plug-in external tools or
 python scripts to process the data. pyxnet features:
 .
  - resources browsing capabilities
  - read and write access to resources
  - complex searches
  - disk-caching of requested files and resources



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112191613.13322.4072.report...@novo.onerussian.com

Bug#609821: ITP: drupal6-mod-charts-graphs -- charts_graphs modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-charts-graphs
  Version : 2.6
  Upstream Author : Irakli Nadareishvili (http://drupal.org/user/96826)
* URL : http://drupal.org/project/charts_graphs
* License : GPL
  Programming Lang: PHP
  Description : charts_graphs modules for Drupal 6

Charts and Graphs is a API for developers. It can easily be extended by 
third-party modules that want to add their own charting implementations. 
It does nothing by itself. It should only be installed if some other 
module requires it.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112192136.10614.13163.report...@a88-114-154-20.elisa-laajakaista.fi

Re: "Mass" (non invasive) NMUs planned to fix debconf translations broken in multiple packages

[Adam D. Barratt]

On Wed, 2011-01-12 at 19:43 +0100, Christian PERRIER wrote:
> My plans are to upload before the end of the upcoming week-end an NMU
> for each of the affected package(s).
> 
> I currently have: 

fwiw, from a quick look at the list, at least boxbackup would need a
t-p-u upload in order to get fixed for squeeze; likewise bugzilla from
Julien's original list.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1294861399.9806.198.ca...@hathi.jungle.funky-badger.org

Bug#609823: ITP: drupal6-mod-swftools -- swftools modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-swftools
  Version : 2.5
  Upstream Author : Stuart Greenfield (http://drupal.org/user/54866)
* URL : http://drupal.org/project/swftools
* License : GPL
  Programming Lang: PHP
  Description : swftools modules for Drupal 6

SWF Tools allows you to easily embed flash content on your pages. 
It supports playlists and rtmp streaming.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112193241.11065.88655.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609824: ITP: drupal6-mod-flashnode -- flashnode modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-flashnode
  Version : 3.1
  Upstream Author : Stuart Greenfield (http://drupal.org/user/54866)
* URL : http://drupal.org/project/flashnode
* License : GPL
  Programming Lang: PHP
  Description : flashnode modules for Drupal 6

Create a flash node, upload an swf file, and hit submit, and you have 
flash on your site. For more advanced use you can combine flash node with 
SWF Tools and flash node will accept flv and mp3 files for easy playback. 
You can use the flash node input filter to re-use your flash content in 
other nodes. Or use PHP to construct flashvars strings to let flash 
elements react to your site.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112193808.11399.70758.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609826: ITP: drupal6-mod-views-charts -- drupal6-mod-views-charts

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-views-charts
  Version : 1.1
  Upstream Author : Irakli Nadareishvili (http://drupal.org/user/96826)
* URL : http://drupal.org/project/views_charts
* License : GPL
  Programming Lang: PHP
  Description : drupal6-mod-views-charts

Provides a "charts" style output for Views module so you can render 
result-set not just as text (list, tabular) but as pie-chart, 
bar-chart, scatter-plot etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112195030.11762.61539.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609827: ITP: drupal6-mod-views-groupby -- views_groupby modules for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-views-groupby
  Version : 1.0-rc2
  Upstream Author : Irakli Nadareishvili (http://drupal.org/user/96826)
* URL : http://drupal.org/project/views_groupby
* License : GPL
  Programming Lang: PHP
  Description : views_groupby modules for Drupal 6

This module enriches Views2 functionality with SQL Grouping and 
Aggregation capabilities.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112195450.12060.39205.report...@a88-114-154-20.elisa-laajakaista.fi

Bug#609834: ITP: deap -- Distributed Evolutionary Algorithms in Python

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 


* Package name: deap
  Version : 0.6
  Upstream Author : DEAP Development Team 
* URL : https://code.google.com/p/deap/
* License : LGPL-3+
  Programming Lang: Python
  Description : Distributed Evolutionary Algorithms in Python

 DEAP is intended to be an easy to use distributed evolutionary algorithm
 library in the Python language. Its two main components are modular and can
 be used separately. The first module is a Distributed Task Manager (DTM),
 which is intended to run on cluster of computers. The second part is the
 Evolutionary Algorithms in Python (EAP) framework.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110112211432.20999.14821.report...@alioth.debian.org

Re: Forwarding bugs upstream

[Jesús M. Navarro]

Hi, Sune:

On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote:
> On 2011-01-11, brian m. carlson  wrote:
> > I've noticed a trend lately that I am often asked to forward the bugs I
> > report to the Debian BTS upstream, either by the maintainers or
> > automatically by a bug script.  I believe, and I continue to believe,
>
> I have considered to take this one step further. Close bugs reported in
> Debian BTS with a severity of important or less that is a bug that
> should primarily be fixed upstream.

Will this mean that the problem will somehow disappear from Debian?  Because 
if it's a problem detected within Debian it's my feeling that it will have to 
be tracked within Debian till the problem is in Debian no more.

> Currently, the debian Qt/KDE team has around 800 open, non-forwarded
> bugs reported against their packages. I would guess that maybe 20 of
> them is packaging issues. But we can't find them.

Start one at a time.

I've been both sides of the wall (as and end user and as being in charge of 
supporting some apps and environments) and here comes my opinion as a "mere 
user with some hindsights".  I'll try to make my points clear, so if someone 
finds them a bit harsh, please understand that it was not my intention, that 
my native language is not English and that my aim is mainly make myself as 
clear as possible:

From the user point of view:

1) A known operational problem that is still there never should map to a 
closed bug, no matter what.  That means that "forwarded upstream", while it 
might be a valid bug state can't be one meaning "closed".  I'm having a 
problem so I'm looking at open problems in the bug database.  That means that 
if there's a problem in, say, Lenny, even if it's demonstrably closed in 
Squeeze it should appear opened when I look for bugs in Lenny.

2) The maintainer took over his shoulders some responsibilities when he became 
maintainer.  When I'm facing a problem with a package in the distribution, 
it's you the one that will have to cope with it.  You'll take my data and 
you'll try to reproduce the bug.  If you are able to reproduce the bug, then 
it's your problem from now on.  If you can't you'll ask me for more data and 
will try to hint which data will be more valuable and will explain to me.

3) Corollary of two is that if you are able to reproduce the bug and you deem 
it to be an upstream one, you should be the one rising it to upstream and 
track it from them on, but since the problem is still there you shouldn't 
close the bug (see 1) but mark/tag it as an upstream problem and that you 
already are dealing with it with upstream at upstream's  bug number.

4) It's not my problem that you lack the time, really.  And no, that you are 
not paid for it it's no excuse either.
Maybe it's that you lack the time for the *boring* side of the task or maybe 
it's that you really don't have the time.  In the first case resign as a 
debian maintainer; in the second one orphan the package.  Debian is proud to 
host a bazillion packages but I really appreciate much more 1/10th of a 
bazillion worth of properly maintained packages than a bazillion of half 
assed ones.  In the first case I know exactly what the situation is, in the 
second I don't know if I'm lucky when I see foo already packaged for Debian 
or if foo will be one of the less than production-ready ones.  It severely 
hinders the overall perception about the quality of the project.

5) I as a user should understand that you are not a magician; without enough 
data you won't be able to deal with my bug and you will have to close it as 
non-reproducible, if I don't feel that to be a good reason I always can go 
anywhere else (say, the upstream developer) to see if I'm more lucky there.

6) There will be (rare) cases when the debian maintainer really won't be in a 
position of being of help.  Then I'll need to understand that, after all, 
it's me the one having a problem, not him, so it's in my best interest to 
take the time going upstream to see what can be done and make the debian 
maintainer (and other who might happen to look at the bug records) know about 
that.

7) Tracking bugs is always a burden so don't expect too much from somebody 
doing it for free.  Try to be helpful since it's in your best interest, say 
thanks with open spirit and, please, take the time to introduce a workaround 
or the solution you found in the bug system so others can benefit out of it 
and the debian maintainer can dedicate his time to something more productive.

From the maintainer point of view:

1) An unreproducible bug is an unexistant bug.  It's valid for unexistant bugs 
not to show in an open bugs list so you are free to close them with a 
non-reproducible message.  If nine out of ten bug reports lack enough data, 
ask for better data and advise that without new data you won't be able to 
reproduce the bug so it will be closed in a decent amount of time (say, two 
weeks? one month?) and then you'll be fr

Bug#609840: ITP: libitext5-java -- Java Library to create and manipulate PDF on the fly

[Andrew Ross]

Package: wnpp
Severity: wishlist
Owner: Andrew Ross 


* Package name: libitext5-java
  Version : 5.0.5
  Upstream Author : Bruno Lowagie, Paulo Soares, et al.
* URL : http://itextpdf.com/
* License : Various: AGPL-3, LGPL, BSD, Apache 2.0
  Programming Lang: Java
  Description : Java Library to create and manipulate PDF on the fly

 iText is a library that allows you to generate PDF files on the fly.
 The iText classes are very useful for people who need to generate read-only,
 platform independent documents containing text, lists, tables and images.
 The library is especially useful in combination with Java(TM)
 technology-based Servlets: The look and feel of HTML is browser dependent;
 with iText and PDF you can control exactly how your servlet's output will look.

Version 5 of the itext library is not backwards compatible with version 2, and 
so to 
avoid version conflicts the new version will be packaged as libitext5-java as 
agreed 
on the debian-java mailing list.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112215312.25627.16731.report...@dolomite

Re: network-manager rant

[Kris Deugau]

Anssi Kolehmainen wrote:

Hi all,

I just updated packages (which upgraded network-manager to 0.8.1-6) and then
rebooted computer. I was greeted with a five minute wait while ntpd tried to
query dns which was broken since network-manager decided to start, ignore
bridge mappings, do dhcp on physical port of the bridge (which of course
breaks the bridge) and clearing out /etc/resolv.conf. Again.


I've "fixed" irregular meddling with my resolv.conf on Debian and other 
distros by:


a) Remove resolvconf, by force if necessary
b) chattr +i /etc/resolv.conf  (yes, I *did* find once instance where 
this was necessary )


-kgd


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d2e2375.5030...@vianet.ca

Re: Forwarding bugs upstream

[Sune Vuorela]

On 2011-01-12, Jesús M. Navarro  wrote:
>> I have considered to take this one step further. Close bugs reported in
>> Debian BTS with a severity of important or less that is a bug that
>> should primarily be fixed upstream.
>
> Will this mean that the problem will somehow disappear from Debian?  Because 
> if it's a problem detected within Debian it's my feeling that it will have to 
> be tracked within Debian till the problem is in Debian no more.

No. but it is a way to be honest about teh issue: We are not spending
debian time on fixing it.

>> Currently, the debian Qt/KDE team has around 800 open, non-forwarded
>> bugs reported against their packages. I would guess that maybe 20 of
>> them is packaging issues. But we can't find them.
>
> Start one at a time.

With more bugs arriving than we are able to close?

> 4) It's not my problem that you lack the time, really.  And no, that you are 
> not paid for it it's no excuse either.
> Maybe it's that you lack the time for the *boring* side of the task or maybe 
> it's that you really don't have the time.  In the first case resign as a 
> debian maintainer; in the second one orphan the package.  Debian is proud to 

Dear Jesus. Are you seriously saying that
 - the kernel mainatiners should step down
 - the xorg maintainers should step down
 - the mozilla maintainers should step down
 - the gnome maintainers should step down
 - the kde maintainers should step down
 - the xfce maintainers should step down
 - the openoffice/libre office maintainers should step down
 - ...

And who do you think should step up ?

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniisda6.rvp.nos...@sshway.ssh.pusling.com

Re: Forwarding bugs upstream

[Ben Finney]

Ian Jackson  writes:

> I think it is always reasonable for the maintainer to forward the bug
> upstream.  
>
> But what I think is bad is _demanding_ or _requiring_ the maintainer
> to forward the bug upstream.  If they don't want to do that for
> whatever reason then asking the submitter to do so is IMO perfectly
> acceptable.

Indeed, the Debian project can't demand or require any work of anyone. I
think it's perfectly acceptable for any such volunteer to refuse to do
the work.

But if they do refuse, then to what extent is that person accomplishing
the maintainer role?

-- 
 \   “All progress has resulted from people who took unpopular |
  `\  positions.” —Adlai Stevenson |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwsxd86t@benfinney.id.au

Re: Forwarding bugs upstream

[Olaf van der Spek]

On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela  wrote:
>> Will this mean that the problem will somehow disappear from Debian?  Because
>> if it's a problem detected within Debian it's my feeling that it will have to
>> be tracked within Debian till the problem is in Debian no more.
>
> No. but it is a way to be honest about teh issue: We are not spending
> debian time on fixing it.

That's better than no response to a bug report at all.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=iivsnrccew4v_p-c_faho6arofrgfdbt8=...@mail.gmail.com

Re: Forwarding bugs upstream

[Russ Allbery]

Ben Finney  writes:

> Indeed, the Debian project can't demand or require any work of anyone. I
> think it's perfectly acceptable for any such volunteer to refuse to do
> the work.

> But if they do refuse, then to what extent is that person accomplishing
> the maintainer role?

I feel like it's rare for any of us, and I'm definitely including myself,
to completely accomplish the maintainer role.  There's always more work
that I could be doing: bugs that are still open, things that could be
improved, project-wide updates that need attention, etc.  While it's
useful to have an idea of that to-do list, I'm not sure it's useful to
beat oneself or others up about not completely accomplishing everything we
want to do as maintainers.  This is a volunteer project, after all (and
even in a non-volunteer project, tasks would be prioritized and some
wouldn't get done because they just weren't high enough priority).

What I think many people are saying in this thread is that, among all the
things that a Debian package maintainer could do to improve the package
and user experience of those using the package, being a go-between for
Debian bug reporters and upstream is something they consider low priority.
It may be something they'd be willing to do if they have free time after
doing other work, or it may be so low-priority that it's below the
threshold of work they're willing to volunteer for, but either way it's
just less important than other things that need doing and therefore will
often go undone.

That seems like a reasonable position to take to me.

I think the question of to what extent a person is accomplishing a
maintainer role is really only a useful question to ask project-wide, in
places like debian-devel (as opposed to personally, when deciding what one
wants to take on) if we're considering either replacing the maintainer or
booting the package for not being properly maintained.  I have a hard time
imagining not forwarding bugs upstream to rise to the level of undone
tasks to warrant contemplating either of those actions in most cases.

Note that most of the push-back against the work of forwarding bugs
upstream is from maintainers of huge packages like X, GNOME, or the
kernel, teams that have been begging for help for years.  We're obviously
not going to kick those packages out of the archive, and we're obviously
not going to replace the existing maintainers given that the problem we're
having is no one volunteering to be a maintainer (and hence no one else is
going to do a better job than the people who are already working on those
packages).  So there doesn't seem to be much point in discussing things
from that angle.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o9du24c@windlord.stanford.edu

Re: List of override disparities

[Kurt Roeckx]

On Tue, Jan 11, 2011 at 11:47:17PM +0100, Luca Falavigna wrote:
> Policy § 2.5 [0] states packages must not depend on other packages with
> lower priority values. In order to better adhere to it, FTP Team
> recently implemented a new tool that generates a list of override
> disparities[1] daily.
> 
> We export a yaml-formatted list, limited to the affected packages only,
> with this group of attributes:
> * package name
> * maintainer
> * priority
> * dependencies with their overrides

Could you add uploaders to that?



Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112235828.ga8...@roeckx.be

Re: Forwarding bugs upstream

[Ben Finney]

Russ Allbery  writes:

> What I think many people are saying in this thread is that, among all
> the things that a Debian package maintainer could do to improve the
> package and user experience of those using the package, being a
> go-between for Debian bug reporters and upstream is something they
> consider low priority. It may be something they'd be willing to do if
> they have free time after doing other work, or it may be so
> low-priority that it's below the threshold of work they're willing to
> volunteer for, but either way it's just less important than other
> things that need doing and therefore will often go undone.
>
> That seems like a reasonable position to take to me.

And to me. None of that argues against the maintainer role entailing
that work, though.

> So there doesn't seem to be much point in discussing things from that
> angle.

Right. My point with raising it was merely to show that it goes both
ways: there's not much point saying “you have to do the work”, just as
there's not much point saying “nobody can force me to do anything”.
Either of those simply polarises the discussion, which is not helpful.

Rather, I'm arguing that the maintainer role, as a mediator and
interface between upstream and the Debian user, entails a whole lot of
different tasks, and being a mediator in the discussion between
upstream-who-doesn't-care-about-Debian-specifically and
Debian-user-with-a-bug-report is part of that role.

To argue that is *not* to require or demand that anyone do any work, nor
to strip anyone of their role. I wish I knew how to avert the seemingly
inevitable charges of that which arise any time we discuss what the
maintainer role entails.

-- 
 \ “When I was a kid I used to pray every night for a new bicycle. |
  `\Then I realised that the Lord doesn't work that way so I stole |
_o__)   one and asked Him to forgive me.” —Emo Philips |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vypd66r@benfinney.id.au

Re: Forwarding bugs upstream

[Felipe Sateler]

On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote:

> I think it is always reasonable for the maintainer to forward the bug
> upstream.
> 
> But what I think is bad is _demanding_ or _requiring_ the maintainer to
> forward the bug upstream.  If they don't want to do that for whatever
> reason then asking the submitter to do so is IMO perfectly acceptable.

We can't demand or require anyone to do anything. Yet we expect 
maintainers to answer bug reports, provide packages, etc. The fact that 
you can't force anyone to do anything doesn't mean you can't say that 
some behavior is preferred or considered best practice.



-- 
Saludos,
Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/iglhb6$8n...@dough.gmane.org

Re: Forwarding bugs upstream

[Ian Jackson]

Olaf van der Spek writes ("Re: Forwarding bugs upstream"):
> On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela  wrote:
> >> Will this mean that the problem will somehow disappear from
> >> Debian?  Because if it's a problem detected within Debian it's my
> >> feeling that it will have to be tracked within Debian till the
> >> problem is in Debian no more.
> >
> > No. but it is a way to be honest about teh issue: We are not spending
> > debian time on fixing it.
> 
> That's better than no response to a bug report at all.

That's true too.

But on the whole I think it would be better to leave these kind of
work-needed upstream bugs open in the Debian BTS but tagged and filed
appropriately.

As I understand it we are not in danger of having infrastructure
capacity problems at the BTS due to these bugs, and the maintainers
who think they are a very low priority don't want to see them can
easily arrange that with the pretty sophisticated filtering and
searching we have nowadays.

But I think that's a matter of best practice and not something I'd
beat a maintainer up about.


I do want to say that from the opposite angle, I do often really
appreciate it when a maintainer has the time to engage with upstream
over my bugs.  I often file bugs in the Debian BTS which are really
upstream bugs because I think this is going to produce a better
overall result for less effort - eg, because Debian and the Debian
maintainer are better organised than the upstream.  Many maintainers
seem to appreciate this too.

But if a maintainer tells me "please go and talk to them yourself" or
even "please stop filing these kind of upstream bugs in Debian - you
know how to do it yourself upstream and I have enough to do already"
then that's a wish I would respect.


So I guess ultimately what I'm saying is that questions like this
can't really be one-size-fits-all.  And it is the maintainer who is
the right person to decide what the best approach is.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19758.18548.460171.590...@chiark.greenend.org.uk

Re: Forwarding bugs upstream

[Ian Jackson]

Felipe Sateler writes ("Re: Forwarding bugs upstream"):
> On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote:
> > I think it is always reasonable for the maintainer to forward the bug
> > upstream.
> > 
> > But what I think is bad is _demanding_ or _requiring_ the maintainer to
> > forward the bug upstream.  If they don't want to do that for whatever
> > reason then asking the submitter to do so is IMO perfectly acceptable.
> 
> We can't demand or require anyone to do anything. Yet we expect 
> maintainers to answer bug reports, provide packages, etc. The fact that 
> you can't force anyone to do anything doesn't mean you can't say that 
> some behavior is preferred or considered best practice.

Yes.

But in this case I don't think we should be "expecting" maintainers to
necessarily shepherd bug reports upstream.  I don't think a maintainer
who fails to do so is failing in their job as maintainer.

The maintainer should decide whether they think doing that is a useful
thing to be doing for that package or that bug, and communicate this
decision to the user (and set the bug state accordingly).

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19758.18829.337578.183...@chiark.greenend.org.uk

Re: Forwarding bugs upstream

[Olaf van der Spek]

On Thu, Jan 13, 2011 at 1:38 AM, Ian Jackson
 wrote:
> But in this case I don't think we should be "expecting" maintainers to
> necessarily shepherd bug reports upstream.  I don't think a maintainer
> who fails to do so is failing in their job as maintainer.
>
> The maintainer should decide whether they think doing that is a useful
> thing to be doing for that package or that bug, and communicate this
> decision to the user (and set the bug state accordingly).

Maybe some tools (PTS) should warn about bugs that are older than X
days and are still unclassified?

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=vahvnar2du9u7r8udza8jcmmh76u0+6wnd...@mail.gmail.com

Re: Forwarding bugs upstream

[Ben Finney]

Ian Jackson  writes:

> As I understand it we are not in danger of having infrastructure
> capacity problems at the BTS due to these bugs, and the maintainers
> who think they are a very low priority don't want to see them can
> easily arrange that with the pretty sophisticated filtering and
> searching we have nowadays.

Yes. If nothing in Debian will happen to a bug report until upstream
gets their act together, tagging to indicate that is fine. Closing the
bug isn't appropriate, since the bug as reported still exists in Debian.

> But I think that's a matter of best practice and not something I'd
> beat a maintainer up about.

Same here.

> I do want to say that from the opposite angle, I do often really
> appreciate it when a maintainer has the time to engage with upstream
> over my bugs.

Perhaps we don't say this enough in public.

> But if a maintainer tells me "please go and talk to them yourself" or
> even "please stop filing these kind of upstream bugs in Debian - you
> know how to do it yourself upstream and I have enough to do already"
> then that's a wish I would respect.

As would I; but, as stated earlier, often the only way I can feasibly
respect such a wish is not to report such bugs at all.

> So I guess ultimately what I'm saying is that questions like this
> can't really be one-size-fits-all. And it is the maintainer who is the
> right person to decide what the best approach is.

Sure, but that's true of just about anything associated with the
maintainer role. It's still good to discuss and argue the various
positions for what the maintainer role should entail.

-- 
 \ “Dad always thought laughter was the best medicine, which I |
  `\guess is why several of us died of tuberculosis.” —Jack Handey |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y66pbnua@benfinney.id.au

Re: Forwarding bugs upstream

[Ian Jackson]

Olaf van der Spek writes ("Re: Forwarding bugs upstream"):
> Maybe some tools (PTS) should warn about bugs that are older than X
> days and are still unclassified?

That's just a way to make more noise.  They show up in the BTS
searches already.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19758.21196.655652.587...@chiark.greenend.org.uk

Bug#609849: ITP: nevernote -- An open source clone designed to interact with Evernote.

[Vincent Cheng]

Package: wnpp
Severity: wishlist
Owner: Vincent Cheng 


* Package name: nevernote
  Version : 0.9.6
  Upstream Author : Randy Baumgarte 
* URL : http://nevernote.sourceforge.net/
* License : GPL-2
  Programming Lang: Java
  Description : An open source clone designed to interact with Evernote.
Nevernote is an open source clone of Evernote,
written in Java  and designed to run on Linux.
Evernote is a collection of   software and
services that allows users to collect, sort, tag and
annotate notes and other miscellaneous information.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110113021157.20316.62790.report...@vincent-laptop.vc.shawcable.net

Bug#609850: ITP: python-mongoengine -- A Python Document-Object Mapper for working with MongoDB

[Janos Guljas]

Package: wnpp
Severity: wishlist
Owner: Janos Guljas 

* Package name: python-mongoengine
  Version : 0.4
  Upstream Author : Harry Marr 
* URL : http://mongoengine.org/
* License : MIT
  Programming Lang: Python
  Description : A Python Document-Object Mapper for working with MongoDB

MongoEngine is a Document-Object Mapper (think ORM, but for document databases) 
for working with MongoDB from Python. It uses a simple declarative API, similar 
to the Django ORM.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110113024421.17238.95120.report...@mac.resenje.org

Re: List of override disparities

[Raphael Geissert]

Luca Falavigna wrote:

> Policy § 2.5 [0] states packages must not depend on other packages with
> lower priority values. In order to better adhere to it, FTP Team
> recently implemented a new tool that generates a list of override
> disparities[1] daily.

There's also:
http://qa.debian.org/debcheck.php?dist=sid&list=main-only-priority&arch=ANY

(debcheck also reports plenty of other things that should be fixed)

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/igm4l9$d5p$1...@dough.gmane.org