On Wed, Nov 12, 2014 at 07:45:44AM +0100, Jean Millet wrote:
Bonjour à tous,
Bonjour.
Nouveau sur cette liste et également dans le développement de paquet .deb,
Mon gros problème est que je ne maîtrise pas l'anglais et je fais donc cette
annonce sur les listes en français. Ce n'est
Le 12/11/2014 09:23, Nicolas Boulenguez a écrit :
On Wed, Nov 12, 2014 at 07:45:44AM +0100, Jean Millet wrote:
Bonjour à tous,
Bonjour.
Nouveau sur cette liste et également dans le développement de paquet .deb,
Mon gros problème est que je ne maîtrise pas l'anglais et je fais donc cette
Bonjour à tous,
Ci-dessous les structures de mes deux premiers essais.
Pour le premier paquet guppy_html.deb pas de problème de compilation, le
paquet est bien créé et s'installe bien dans /usr/var/www/html/ et
dossier guppy (c'est également OK dans var/www/ ou autre en modifiant
Vous l'installiez sur /usr/share , puis vous faites un shell script qui
sera installer sur /usr/bin , qui fera le déplacement et la configuration
selon le serveur de l'utilisateur
On Thursday, November 13, 2014, Jean Millet jean.mil...@free.fr wrote:
Bonjour à tous,
Ci-dessous les
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote:
Please discourage the use of pristine-tar. The format is fragile and can
suffer from bit rot.
I am not personally interested in pristine-tar, but I don't think this is the
right place to take a stance on its use.
--
To
On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote:
Personally I wouldn't use anything other than debian-only repos, at
least for those where I have a choice. I also actively avoid
contributing to packages that don't use such repos.
And I'm the exact opposite.
--
To UNSUBSCRIBE,
Jonathan == Jonathan Dowland j...@debian.org writes:
Jonathan On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote:
Personally I wouldn't use anything other than debian-only repos, at
least for those where I have a choice. I also actively avoid
contributing to packages
On Friday 07 November 2014 17:04:10 Joey Hess wrote:
It's become abundantly clear that this is no longer the project I
originally joined in 1996. We've made some good things, and I wish
everyone well, but I'm out.
I'm very sorry to read this. We'll miss you.
All the best
--
Hi,
On Tue, 11 Nov 2014, Iustin Pop wrote:
Packaging branches and tags
===
Packaging branches should be named according to the codename of the
target distribution. In the case of Debian, that means for example
`debian/sid`, `debian/jessie`,
Hi,
Jonathan Dowland:
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote:
Please discourage the use of pristine-tar. The format is fragile and can
suffer from bit rot.
I am not personally interested in pristine-tar, but I don't think this is the
right place to take a stance
On Wed, 12 Nov 2014, Matthias Urlichs wrote:
If the package maintainers use the pristine-tar tool to efficiently store
a byte-for-byte copy of the upstream tarballs, this should be done in the
`pristine-tar` branch.
Please discourage the use of pristine-tar. The format is fragile and can
Paul Wise p...@debian.org writes:
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and briefly mention it as an
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg ebo...@apache.org
* Package name: noggit
Version : 0.6
Upstream Author : Yonik Seeley ysee...@gmail.com
* URL : http://github.com/yonik/noggit
* License : Apache-2.0
Programming Lang: Java
Description
On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
In fact, I was quite non-amused by the initial versions of this idea, but
reading this latest version, I must say I *like* it. Well done! I am
especially happy about the way it respects the usual git usage conventions,
this will ease
On Tue, 11 Nov 2014, Barry Warsaw wrote:
One question: when this gets adopted, will individual maintainers or teams
have to know which of the git packaging helpers a particular repository is
using? IOW, what happens if I were to use gbp-pq on a package that someone
else had used git-dpm on?
[ Ccing the maintainers of git packaging helper tools ]
Hi Scott,
using your mail as an opportunity to explicity notify the respective
package maintainers of this ongoing DEP.
Guido, Bernhard, Ron, if you are not reading debian-devel, I would
like to bring your attention to a discussion that I
On Wed, 12 Nov 2014, Mathieu Parent wrote:
A paragraph about repacked upstream is needed. A lot of packages are
currently stripped for minified JS, non-free additions, included RFCs,
... What would the upstream/1.x branch be then? Maybe add an
upstream/1.x+debian branch?
Yeah, that was
Hi Gergely,
On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael When releasing a Debian package, the packager should create and
push
Raphael a signed tag named `vendor/version`. For example, a Debian
maintainer
Raphael releasing a package with version 2:1.2~rc1-1 would create a
On Wed, Nov 12, 2014 at 10:02 AM, Raphael Hertzog hert...@debian.org wrote:
for the current Ubuntu development series. If I needed to support older
releases in either distro, then debian/wheezy or ubuntu/utopic would be good
branches to use. (Or IOW, what's the equivalent of debian/sid for
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
better than people leaving outright?
--
To
2014-11-12 10:28 GMT+01:00 Raphael Hertzog hert...@debian.org:
On Wed, 12 Nov 2014, Mathieu Parent wrote:
A paragraph about repacked upstream is needed. A lot of packages are
currently stripped for minified JS, non-free additions, included RFCs,
... What would the upstream/1.x branch be
On Sat, 8 Nov 2014, Stuart Prescott wrote:
UDD can help with this.
A list of source packages that have M-A: same binary packages in jessie that
have different versions in any two release architectures is at:
Can we do this for the triplet (i386, amd64, x32) too, please?
Yes, it’s not a
On Fri, 7 Nov 2014, Ralf Treinen wrote:
architecture-specific. The issue of architecture=all packages that
are not installable on some architecture can IMHO not be solved with
our current setup which makes architectures=all available on every
architecture.
This is a bug, I’ve seen this
On Wed, 12 Nov 2014 11:04:05 +0100
Daniel Pocock dan...@pocock.pro wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto
On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote:
This is a bug, I’ve seen this affect buildd dependency resolution,
and anyway, if it’s not installable everywhere, why is it arch:all?
I would guess that uninstallable arch:all things happens when they
depend on non-portable things. For
* Daniel Pocock dan...@pocock.pro, 2014-11-12, 11:04:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would
On 12/11/14 11:43, Andrey Rahmatullin wrote:
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a
Hi!
On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote:
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and
Le 11/11/2014 22:26, Raphael Hertzog a écrit :
Hello,
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's now online at
On Tue, 11 Nov 2014, Raphael Hertzog wrote:
QUESTION: some people have argued to use debian/master as the latest
packaging targets sometimes sid and sometimes experimental. Should we
standardize on this? Or should we explicitly allow this as an alternative?
Given the feedback received,
Hi,
On Wed, 12 Nov 2014, Thibaut Paumard wrote:
I see nothing about whether the debian branch should contained the
unpacked or the unpacked *and* patched sources, and whether to ship the
.pc directory.
I personally ship the unpatched sources and don't ship the .pc directory.
That's a
On 12/11/14 10:04, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
better
Hi Raphael,
On Wed, Nov 12, 2014 at 10:15:27AM +0100, Raphael Hertzog wrote:
Hi Scott,
using your mail as an opportunity to explicity notify the respective
package maintainers of this ongoing DEP.
Guido, Bernhard, Ron, if you are not reading debian-devel, I would
like to bring your
Thanks for all the nice info Paul!
*t
Am 12.11.2014 um 06:59 schrieb Paul Wise:
On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote:
would any of you come and sign my key when in Zürich/SH/Winti?
In case folks from these places aren't reading this list, some possibilities:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please no.
We need less and not more layers of governance/'political' complexity in
project. Lets stop acting like government and more like community.
Cheers,
zlatan
On 12 November 2014 11:04:05 CET, Daniel Pocock dan...@pocock.pro wrote:
It
On 12/11/14 13:12, zlatan wrote:
Please no.
We need less and not more layers of governance/'political' complexity
in project. Lets stop acting like government and more like community.
If a veto facility is created effectively, then it will deter people
from complexity and force people back
Hi Daniel,
aint the GR process exactly that, a way to say veto? Compare the current
vote...
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org
* Package name: python-oslo.middleware
Version : 0.1.0
Upstream Author : OpenStack Developers openstack-...@lists.openstack.org
* URL : https://github.com/openstack/oslo.middleware
* License
On Wed, Nov 12, 2014 at 01:41:33PM +0100, Daniel Pocock wrote:
Please no.
We need less and not more layers of governance/'political' complexity
in project. Lets stop acting like government and more like community.
If a veto facility is created effectively, then it will deter people
from
On 12/11/14 05:54, Mathieu Parent wrote:
Also, the vendor/* branches heads should be at a descendent commit of
the corresponding upstream branch, diffing only by the debian dir.
This is only true for workflows similar to the one normally used with
gbp-pq, in which desired patches are serialized
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org
* Package name: python-oslo.concurrency
Version : 0.2.0
Upstream Author : OpenStack developers openstack-...@lists.openstack.org
* URL : https://github.com/openstack/oslo.concurrency
* License
Hi Ron,
On Wed, 12 Nov 2014, Ron wrote:
I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much)
into details of the various workflows and why I try to restrict
the DEP at simple naming conventions for branches and tags
Package: wnpp
Severity: wishlist
Owner: Allen Riddell abr+deb...@fastmail.fm
* Package name: python-lda
Version : 0.3.2
Upstream Author : lda developers lda-us...@googlegroups.com
* URL : https://pypi.python.org/pypi/lda
* License : MPL-2
Programming Lang:
On Wed, 12 Nov 2014, Mathieu Parent wrote:
Maybe a short note would be good then? (but I don't know how to write it).
I suggest this:
--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -230,6 +230,17 @@ non-patchable data), you can do so but you should then
document
this in
Hi,
Simon McVittie:
Is it the intention of this DEP to mandate the gbp-pq-like repo
structure, which basically forbids use of tools whose design does not
match that? Or is the intention to set some conventions that can be true
regardless of whether you are using a more gbp-pq-like or more
Ben Finney writes (Re: Removing duplication: Word lists of common words in
languages):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I had roughly this question in 2013, and found the answer. Here is
probably the best starting point:
On 12/11/14 13:38, Matthias Urlichs wrote:
IMHO there are two basic approaches which are mostly at odds with
each other.
I think there are at least three.
Two: Treat Upstream tarballs as Source Code; if Upstream generates
them from git-or-whatever, that's not our problem. Use a script to
Raphael Hertzog writes (RFC: DEP-14: Recommended layout for Git packaging
repositories):
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's
Barry Warsaw writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:
Vendor namespaces
-
Each vendor uses its own namespace for its packaging related
Git branches and tags: `debian/*` for Debian,
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
The DEP will neither encourage and discourage its use. It only mentions
that if a maintainer is using it, it should store pristine-tar data
in the pristine-tar branch.
Would it be worth mentioning in
Scott Kitterman writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Who's going to do patches to existing tools (e.g. git-dpm is the one
I use and care about) so they comply with this and similarly scripts
to convert existing git repos to match this recommendation?
Hi,
Simon McVittie:
Keep Debian packaging completely separate (in a different branch,
or even in a diffferent archive) and use a quilt-ish workflow
Let's call this one divided.
Three: same as Two, but the Debian packaging branch is branched from
the upstream branch, so it contains
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On 12/11/14 05:54, Mathieu Parent wrote:
Also, the vendor/* branches heads should be at a descendent commit of
the corresponding upstream branch, diffing only by the debian dir.
...
Concrete example:
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs matth...@urlichs.de
wrote:
Hi,
Simon McVittie:
Is it the intention of this DEP to mandate the gbp-pq-like repo
structure, which basically forbids use of tools whose design does not
match that? Or is the intention to set some conventions
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
+When you have good reasons to only store the `debian` packaging directory
+(for example when the uptream sources are really huge and contains mostly
+non-patchable data), you can do so but you should
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
For development releases
Packages uploaded to the current development release should be prepared
in a `vendor/master` branch.
I preferred the previous text for this
On November 12, 2014 8:15:02 AM CST, Scott Kitterman deb...@kitterman.com
wrote:
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
matth...@urlichs.de wrote:
Hi,
Simon McVittie:
Is it the intention of this DEP to mandate the gbp-pq-like repo
structure, which basically forbids use of tools
Matthias Urlichs writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
This DEP describes an integrated workflow.
That's true right now. But I think a document called `Recommended
layout for Git packaging repositories' ought to cover the reasonable
possibilties which are
Ian Jackson writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
I think you need to be more explicit about the implications for `3.0
(quilt)' format packages. Something like:
If the git tree contains debian/format specifying `3.0 (quilt)',
the git tree must
On 12/11/14 14:12, Ian Jackson wrote:
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
In the gbp-pq world, after git checkout debian/sid, hello.c would
contain hello, world, but there would be a patch in debian/patches/ to
change it from hello,
On Wed, 12 Nov 2014, Ian Jackson wrote:
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git
packaging repositories):
The DEP will neither encourage and discourage its use. It only mentions
that if a maintainer is using it, it should store pristine-tar data
in the
Hi Ian,
On Wed, 12 Nov 2014, Ian Jackson wrote:
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git
packaging repositories):
+When you have good reasons to only store the `debian` packaging directory
+(for example when the uptream sources are really huge and contains mostly
2014-11-12 14:29 GMT+01:00 Raphael Hertzog hert...@debian.org:
On Wed, 12 Nov 2014, Mathieu Parent wrote:
Maybe a short note would be good then? (but I don't know how to write it).
I suggest this:
--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -230,6 +230,17 @@ non-patchable data),
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Much like we have a default desktop environment we should have a default
layout for a git packaging repository.
There's an argument for that.
Of course (donning my partisan colours) I think the answer
On Wed, 12 Nov 2014, Ian Jackson wrote:
It doesn't make much sense to have an standard unless there's also a plan
to
implement using it.
I thought Raphael was trying to document existing practice.
The problem is that existing practices are not uniform and vary between
helper tools
Hi,
On Wed, 12 Nov 2014, Ian Jackson wrote:
Simon, would you care to write up a concrete text documenting the
conventional divided layouts ? Raphael, I guess you have the DEP in
git. Where's the repo ? Wait, what, it's in the webtree in ...
is that still CVS ?
It's in the dep SVN
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung benjamin.dr...@profitbricks.com
* Package name: graypy
Version : 0.2.11
Upstream Author : Sever Băneşiu banesiu.se...@gmail.com
* URL : https://github.com/severb/graypy
* License : BSD
Programming Lang:
On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito rogerbr...@uol.com.br wrote:
On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place.
Does this mean that I should ask
On Wed, Nov 12, 2014 at 07:17:59AM +0100, Andreas Tille wrote:
Hi Santiago,
On Tue, Nov 11, 2014 at 10:24:11PM +0100, Santiago Vila wrote:
So, would this patch to the current r-base package improve things if
applied to the version in unstable?
[...]
While this would create a versioned
On 11/12/2014 07:08 PM, Daniel Pocock wrote:
On 12/11/14 11:43, Andrey Rahmatullin wrote:
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people
On Nov 12, 2014, at 10:02 AM, Raphael Hertzog wrote:
I don't know. My long term hope is that in this process we will get to a
situation where:
- either the tools are sufficiently interoperable that we don't have to
care about this
- or one of tools emerges as standard supporting all the
On Wed, Nov 12, 2014 at 12:11:12PM +0100, Guillem Jover wrote:
Hi!
On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote:
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too.
On 12/11/14 17:42, Scott Howard wrote:
On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito rogerbr...@uol.com.br wrote:
On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first
On 12/11/14 17:47, Thomas Goirand wrote:
On 11/12/2014 07:08 PM, Daniel Pocock wrote:
On 12/11/14 11:43, Andrey Rahmatullin wrote:
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to
Daniel Pocock dan...@pocock.pro writes:
On 12/11/14 17:47, Thomas Goirand wrote:
On 11/12/2014 07:08 PM, Daniel Pocock wrote:
On 12/11/14 11:43, Andrey Rahmatullin wrote:
On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/11/14 18:36, Philip Hands wrote:
Daniel Pocock dan...@pocock.pro writes:
On 12/11/14 17:47, Thomas Goirand wrote:
On 11/12/2014 07:08 PM, Daniel Pocock wrote:
On 12/11/14 11:43, Andrey Rahmatullin wrote:
On Wed, Nov 12, 2014 at
On Wed, Nov 12, 2014 at 06:44:50PM +0100, Daniel Pocock wrote:
You're expecting people proposing GRs to be receptive to rational
argument.
I fear you've not been paying close attention recently. Well
done. I congratulate you on your wisdom.
If rational argument is not necessary, then
On 11/12/2014 02:04 AM, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
better than
On 11/11/14 22:26, Raphael Hertzog wrote:
Hello,
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's now online at
On Nov 12, 2014, at 09:27 AM, Matthias Urlichs wrote:
Then we should either remove the paragraph entirely, or at least mention
the danger of bit rot and that it's unwise to rely on being able to recover
the tarfile (long term).
Because the vast majority of upstream Python packages are released
On Wed, Nov 12, 2014 at 09:21:56AM +0100, Raphael Hertzog wrote:
Hi,
On Tue, 11 Nov 2014, Iustin Pop wrote:
Packaging branches and tags
===
Packaging branches should be named according to the codename of the
target distribution. In the case of Debian,
Control: reassign -1 wnpp
Control: severity -1 wishlist
Control: owner -1 Bhavyanshu Parasher a...@bhavyanshu.me
Your mailer messed up the line breaks, trying to fix.
* Package name : lightmdeditor
Version : 1.0-2
Upstream Author : Bhavyanshu Parasher a...@bhavyanshu.me
* URL :
On Wed, 12 Nov 2014, Raphael Hertzog wrote:
On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
In fact, I was quite non-amused by the initial versions of this idea, but
reading this latest version, I must say I *like* it. Well done! I am
especially happy about the way it respects the
On Tue, 11 Nov 2014, Rogério Brito wrote:
On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place.
Does this mean that I should ask for the removal of youtube-dl
Raphael == Raphael Hertzog hert...@debian.org writes:
Raphael Hi Gergely,
Raphael On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael When releasing a Debian package, the packager should create and
push
Raphael a signed tag named `vendor/version`. For example, a Debian
maintainer
On Wed, 12 Nov 2014 13:20:01 +0100, zlatan wrote:
We need less and not more layers of governance/'political' complexity in
project. Lets stop acting like government and more like community.
When you have a small number of people involved in a 'community' then you
can get by with little
Hi Simon,
(Please CC me on these, I'm not currently subscribed to -devel, and I'm
catching up from the list archives. At the very least it will make it
easier to avoid accidentally breaking the threading :)
On 12/11/14 05:54, Mathieu Parent wrote:
Also, the vendor/* branches heads should be
On Wed, 12 Nov 2014, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
better than
* Daniel Pocock (dan...@pocock.pro) [141112 13:42]:
On 12/11/14 13:12, zlatan wrote:
Please no.
We need less and not more layers of governance/'political' complexity
in project. Lets stop acting like government and more like community.
If a veto facility is created effectively, then
On Wed, Nov 12, 2014 at 02:14:55PM +0100, Raphael Hertzog wrote:
Hi Ron,
On Wed, 12 Nov 2014, Ron wrote:
I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much)
into details of the various workflows and why I try
Andrey Rahmatullin w...@debian.org writes:
On Wed, Nov 12, 2014 at 01:41:33PM +0100, Daniel Pocock wrote:
If a veto facility is created effectively, then it will deter people
from complexity and force people back to looking for consensus
Or we could fix the TC instead.
It would be lovely if
Hi.
I've read the original proposal and believe it is generally going in the
right direction.
things I liked:
* didn't pick between dgit/git-dpm/git-pq; documented the common parts
* Seemed to really focus on one clear scope.
* Discouraged overlay packaging.
I've tried to read the arguments,
On Wednesday 12 November 2014 10:47:30 Raphael Hertzog wrote:
[snip]
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and briefly mention it as an option.
I find it a
Daniel Pocock dijo [Wed, Nov 12, 2014 at 12:08:23PM +0100]:
I didn't want to be too specific, to give other people a chance to make
suggestions
However, one possibility is that anybody maintaining an essential
package and anybody who is a DPL delegate would be able to veto. The
implication
Package: wnpp
Severity: wishlist
Owner: Balasankar C balasank...@autistici.org
* Package name: ruby-notifier
Version : 0.5.0
Upstream Author : Nando Vieira fnando.vie...@gmail.com
* URL : https://github.com/fnando/notifier
* License : Expat
Programming Lang:
* Neil McGovern (ne...@debian.org) wrote:
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
57dd4d7c-3e92-428f-8ab7-10de5172589e
[ 5 ] Choice 1: Packages may not (in general) require a specific init system
[ 3 ] Choice 2: Support for other init systems is recommended, but
On 13/11/14 06:29, Gunnar Wolf wrote:
Daniel Pocock dijo [Wed, Nov 12, 2014 at 12:08:23PM +0100]:
I didn't want to be too specific, to give other people a chance to make
suggestions
However, one possibility is that anybody maintaining an essential
package and anybody who is a DPL delegate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 12 Nov 2014 08:00:40 +
Source: libcatalyst-perl
Binary: libcatalyst-perl
Architecture: source all
Version: 5.90075-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 05 Oct 2014 14:35:21 +0800
Source: ironic
Binary: python-ironic ironic-common ironic-api ironic-conductor ironic-doc
Architecture: source all
Version: 2014.1-10
Distribution: unstable
Urgency: medium
Maintainer: PKG OpenStack
1 - 100 of 164 matches
Mail list logo
