date:20120625

Dublin, Ireland bug squashing party

2012-06-25 Thread Philip Ashmore


Hi there.

It's come to my attention that bug squashing parties are _the_ way to 
fix bugs.


Not to be seen as uncool, I'm proposing a bug squashing party somewhere 
in Dublin, Ireland at a mutually agreed date and time.


I'm just canvassing for support right now, as I don't know the Debian 
procedure for doing this - or even if there is one.


One of the topics/issues/bugs I hope to address is getting my open 
source projects in SourceForge knocked into shape for acceptance into 
Debian.


I don't know if that meets the criteria for party - maybe a shindig or 
a hootenanny.


Regards,
Philip Ashmore


--
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/4fe7fe98.1030...@philipashmore.com

Re: duplicates in the archive

2012-06-25 Thread Antti-Juhani Kaijanaho



Adam Borowski kilob...@angband.pl kirjoitti:

Sure, let's start removals with ones that hard-depend on things a
window
manager shouldn't touch, like network-manager. 

Which wm does that? I know it isn't gnome-shell at least, as I've been
using it quite successfully without nm installed.

(I hope this message looks okay - I'm sending from an unfamiliar
MUA.)
-- 
Antti-Juhani


-- 
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/1eb44713-6893-4e9d-9cb5-9fd07e0c5...@email.android.com

Re: duplicates in the archive

2012-06-25 Thread Bart Martens

On Sun, Jun 24, 2012 at 10:18:00PM +0100, Neil Williams wrote:
 On Sun, 24 Jun 2012 20:48:43 +
 Bart Martens ba...@debian.org wrote:
 
  On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
   Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : 
What makes 42 window manager acceptable but not 43?
   
   Who said 42 is acceptable?
  
  The neglected ones should be removed.  If they're all well maintained and 
  all
  used, then 43 is acceptable, in my opinion.
 
 There is general agreement that neglected ones should be removed, it
 just comes down to someone doing the work and making that assessment.

True.

 If
 you're interested, file the RM bugs in time for wheezy.

You question those 42 implementations, so you can analyse them, file RM bugs
where appropriate, and write a justification for rejecting #43.

 
 Feel free to re-use a similar measure/approximation for neglect as I
 blogged about for the measure/approximation of rubbish. (Linked from
 my homepage below.)

If that text reflects consensus, then feel free to make
http://qa.debian.org/howto-remove.html point to that text.

 
 With any objective analysis of the current 42, I find it impossible to
 believe that all 42 would re-qualify.

Good, you seem to have already started with analysing those 42 implementations.

 
 Of course, someone who wanted to introduce #43 may be the person in
 the right place to do the analysis. 

This person may be in the right place to do the analysis, but I don't think
that this person must do that analysis.

 
 It isn't a small task - if it doesn't get done for wheezy it's not that
 bad but

The coming freeze period may be a good time for spending time on removals by
anyone interested.

 it does seem justified before #43 arrives.

It is not bad/wrong that you want that analysis to be done now.

 I'd expect that the
 process itself shows that #43 isn't actually needed at all and that
 whatever is desired can be achieved by patching one of the existing
 ones.

Yes, the analysis may result in the conclusion that #43 is not needed in
Debian.  But please don't reject #43 just because nobody (not you, not the ITP
submitter, not any volunteer) has compared it with the 42 other
implementations.

Regards,

Bart Martens


-- 
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/20120625062421.gb17...@master.debian.org

Re: duplicates in the archive

2012-06-25 Thread Russ Allbery

Neil Williams codeh...@debian.org writes:

 Whatever happens, there is no place for yet another duplicate of
 packages which already have multiple duplicates in the archive.

I think it's hard to defend the contention that the quantity of packages
has some strong relationship to whether or not those programs duplicate
the functionality of other programs.  Surely it also depends on the type
of program, rather heavily.

For example, I'm sure that we have more than 42 different programming
languages in the archive, so obviously we don't need Java, right?  You can
do all the same things in C++.  Or hey, let's pick one of either Perl or
Python; they can both do the same things.

I can definitely come up with more than 42 different ways to write an
editor, all of which may appeal to different people, different tasks, or
different work styles.  But hey, I like Emacs, which clearly does
everything that vi can do, so away with vim!  And nvi just duplicates vim!

We probably don't need 42 different ways to find duplicate files on local
disk, since that's a relatively clear and well-defined task and there's
only so many ways to go about it (and each implementation could probably
gain the features of the others).  But window managers are fundamental to
one's style of interaction with the computer, and there are *huge*
differences between them.  A tiling window manager is not interchangeable
with a desktop environment, which in turn is not interchangeable with a
window manager designed to be operated without a mouse, or one that's
optimized for a particular class of accessibility issues.  And that's not
even getting into the window managers that are used primarily because they
embed a particular scripting language that people want to use to automate
their windowing actions.

By all means, let's get rid of packages that really do only offer subsets
of functionality of other packages.  But UI is part of functionality, and
a different UI *is* a different feature.  By all means, let's get rid of
poorly-maintained packages.  But if someone finds a package that does
something in a way that nothing else does and that fits them, and they're
able and willing to take care of it, having a place for those is one of
Debian's strengths.  We should be improving our tools and management
techniques for handling large numbers of packages, including for retiring
them when they're not being maintained, not trying to reduce the variety
and depth of the distribution.

And as sympathetic as I am to the concern about RC bugs in packages that
are already in the archive, I suspect it's rather rare that fixing random
RC bugs in other people's packages is the compelling, fun thing that gets
someone involved in doing Debian development.  I know it happens, but I
bet more people join the project the way that I did: there's some specific
piece of software that they want packaged for the distribution they
already use, so they package it, and from that learn how to package, and
from that branch out into helping with other parts of the distribution.

Getting one's own package into the distribution is a really awesome
feeling.  I don't think it's good for the growth of the project, or for
attracting new contributors, to put too many roadblocks in the way of
someone feeling that.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87k3yvgai6@windlord.stanford.edu

Re: duplicates in the archive

2012-06-25 Thread Bart Martens

On Sun, Jun 24, 2012 at 08:36:13PM +0100, Neil Williams wrote:
 On Sun, 24 Jun 2012 20:42:33 +0200
 Arno Töll a...@debian.org wrote:
 
  On 24.06.2012 19:51, Neil Williams wrote:
   Whatever happens, there is no place for yet another duplicate of
   packages which already have multiple duplicates in the archive.
  
  Letting alone the package in particular (I don't even know it, nor do I
  care)
 
 (Neither do I, particularly - but Thomas' list made it just too
 obvious that there was no justification for the bug report at the time
 of filing.)
 
 , I wonder where you'd draw that line. As you say yourself: There
  are lots of alternative packages in the archive already. So, what makes
  all the other alternatives acceptable but this one not?
  
  What makes 42 window manager acceptable but not 43?
 
 If it can be justified. That's what the objective comparison would need
 to demonstrate.

The rejection of #43 should be justified, for example with conclusions from
such comparison with the 42 other implementations.

 That's an established pattern in Debian -

Let's not call your personal view an established pattern in Debian.  Let's
debate this and find a consensus before documenting it and advertising it as
an established pattern in Debian.

 if someone
 wants to add something which is the same as something else, there
 should be a good reason to introduce the new one in that it needs to be
 better than the existing ones in some way which isn't achievable just
 by patching one of the existing ones.

It is, in my opinion, OK that someone expresses an intent to package a 43th
implementation in public so that anyone can compare it with the 42 other
implementations and then argue why #43 would not be needed in Debian.


 Debian works on merit - packages and maintainers. Suggesting or
 packaging something which is without merit will usually result in
 complaints from your peers. Cope with it. Maintainers should not expect
 to be treated with kid gloves when what they are actually doing is
 wasting the free time of other volunteers.

You can prevent your free time from being wasted by ignoring this ITP.  If you
actively want to keep the package of this ITP out of Debian, then you should
produce some reasonable arguments, maybe after comparing all 43
implementations.  But then it's your choice for doing all that work.  Please
don't blame the ITP submitter for wasting your time.

 
 We're used to 'Justification' as a concept for RC bugs, well an ITP is
 a bug in Debian and can also require justification. Some ITP bugs are
 simply invalid.

An ITP is an expression of an intent to package some software.  It does by
itself not express I have analysed every alternative in Debian and I think
this one is better.  If you feel that this one is not better, then you should
justify the rejection of the ITP.

 
 Someone needs to make that call and as we're all part of the QA team,
 various people do it according to their own free time, work area,
 expertise and general levels of annoyance with daft ideas.

Yes, anyone can justify why an ITP should be rejected.

 
 Whether it's a joke package or a tiny package which needs to go into a
 collective package (goodies or devscripts or whatever), if maintainers
 (prospective or existing) can't do their own research ahead of filing a
 bug, it is up to the rest of us to point out the error.

Yes, you're right about this.  That's what I understand in peer review.

 
  I'm not in favor to get yet another window manager in Debian. All I'm
  saying is that filing a WNPP bug and wait whether a people complain loud
  enough is not the way to learn that.

I think that it is OK that other people complain about an ITP.  It is also OK
to be very clear about why an ITP in particular is not welcome.  Of course,
politeness and friendliness are generally appreciated, and I think that this
aspect started the debate.

 
 So feel free to file a patch to the Developer Reference explaining that
 if maintainers of prospective packages don't check for existing packages
 which provide the same or very similar functionality, any request to
 package such a duplicate needs to be accompanied by a detailed
 reasoning of *why* the existing packages are sufficiently inadequate
 that a new package is warranted instead of patching what we have.

If you feel that Developer Reference can be improved, then feel free to do
suggestions.  The above is not a suggestion I can support.

 
 To me, such an expectation is common sense and I'm quite happy to
 continue criticising ITP's on the basis of being an unjustifiable
 duplicate of existing packages.

It is good that you continue reviewing ITPs.  But I would appreciate (and the
ITP submitter would probably also appreciate) that you justify rejecting ITPs
with good arguments and in a friendly way.

 
  Especially since a WNPP bug
  complaints are not worth that much. If you happen to find a DD to upload
  your stuff or you are DD yourself, you can silently ignore any

Re: Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze

2012-06-25 Thread Simon McVittie

On 25/06/12 06:07, YunQiang Su wrote:
 1. upload 2.0 to experimental, and unstable users should install it manually.

This is usually the right answer: if version 1.0 is intended to go in
the next Debian release, it should get as much testing as possible,
which means it should be the default for unstable users.

 And I am also confused by the connection of proposed-updates and updates.

Updates to stable or testing aren't official until the release team
has acknowledged them. You discuss the update with the release team,
then (if they approve) upload to *-proposed-updates. The release team
review the update and copy it to *-updates.

S


-- 
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/4fe81825.6040...@debian.org

Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch

2012-06-25 Thread Serge

2012/6/24 Thomas Koch wrote:

Package: wnpp
Severity: wishlist
Owner: Mickaël Raybaud-Roig raybaudro...@gmail.com

* Package name: wmfs
Version : 2~beta201206
Upstream Author : Martin Duquesnoy xor...@gmail.com
* URL : http://wmfs.info
* License : BSD
Programming Lang: C
Description : Window Manager From Scratch

« WMFS2 is a lightweight and highly configurable tiling window manager
for X written in C. wmfs2 is a free software distributed under the BSD
license. it can be drive from keyboard or mouse and it's configuration
stands in one text file easily understandable »

Users reading such description can be confused how is it different from
other existing WMs. So let's put some more details in this description:
Its features include:
* extendible application launcher with autocompletion (prompt).
* built-in system tray.
* Xinerama multi-head support.
* extended window manager hints (EWMH) compliance.
* editable rules for tags/clients.
* complete mouse support.
* on-the-fly configuration reloading.
* dynamic tag creation/deletion.
* statusbar with support for progressbar, color, images and status pipes.
* manual layout: you can create/arrange layouts as you want/need.
* tab, move and resize clients with direction.
* themes support for statusbar and clients.
* ”@include” support split configuration file.

At least that statusbar feature worth to be mentioned, since it makes
this WM unique. EWMH, themes and built-in system tray looks also
important to me.

As a user I would also like to know:
* what's its focus model: focus-follows-mouse, click-to-focus, etc?
* does it have a GUI configuration?
* does it support workspaces?
* does it allow to move windows with mouse?
* does it support urgency hints (WM_HINTS, NET_WM_STATE_DEMANDS_ATTENTION)?
* is it just tiling? what about stacking mode or floating windows?
* is it utf8/unicode friendly? works for window titles in french or korean?
* is it translated to other languages?
* freetype/Xft or X core fonts?
* shape extension? round windows? (e.g. `xeyes`)
* how much RAM it takes?
* is it low-dependency (GTK/Qt/Tk/etc.)?

As a start point: what are its differences from i3-wm, awesome or wmii?

I shortened the list to only include one line for each window manager
already in Debian:
[...]

Among those 41 WMs only 9 are tiling WMs. And just a few of those tiling
WMs are usable out-of-box without heavy configuring and long documentation
reading.

PS: IMHO, there's nothing bad in having several similar programs in
repository, as long as someone wants to maintain them. It gives additional
flexibility for users. I.e. if some of them die upstream or dropped by the
maintainer users would be able to use another one.

--
Just trying to help,
Serge

--
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/caovenepv5zh0w9ke67rdosgwp4rvamkfdrxj5ewa+nm2q+f...@mail.gmail.com

1 2 3 >

1 - 100 of 266 matches

Mail list logo