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 d
* 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 n
Package: wnpp
Severity: wishlist
Owner: Balasankar C
* Package name: ruby-notifier
Version : 0.5.0
Upstream Author : Nando Vieira
* URL : https://github.com/fnando/notifier
* License : Expat
Programming Lang: Ruby
Description : send system notification
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
> implic
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 fi
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, an
Andrey Rahmatullin 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 that were
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
* 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 effect
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
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
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
> "Raphael" == Raphael Hertzog 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 `/`. For example, a Debian
maintainer
Raphael> releasin
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
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 respec
Control: reassign -1 wnpp
Control: severity -1 wishlist
Control: owner -1 Bhavyanshu Parasher
Your mailer messed up the line breaks, trying to fix.
> * Package name : lightmdeditor
> Version : 1.0-2
> Upstream Author : Bhavyanshu Parasher
> * URL : https://github.com/bhavyanshu/lightmd_edit
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 c
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 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 http://dep.debian.
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 p
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 necess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/11/14 18:36, Philip Hands wrote:
> Daniel Pocock 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:05
Daniel Pocock 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 that t
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
On 12/11/14 17:42, Scott Howard wrote:
> On Tue, Nov 11, 2014 at 2:35 PM, 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.
>>
>> D
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 reposito
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 imp
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
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 giv
On Tue, Nov 11, 2014 at 2:35 PM, 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
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung
* Package name: graypy
Version : 0.2.11
Upstream Author : Sever Băneşiu
* URL : https://github.com/severb/graypy
* License : BSD
Programming Lang: Python
Description : Python logging handler that s
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 repo
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 too
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 a
2014-11-12 14:29 GMT+01:00 Raphael Hertzog :
> 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 d
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
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
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 fr
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
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 a
On November 12, 2014 8:15:02 AM CST, Scott Kitterman
wrote:
>On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
> 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
>>>
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 `/master` branch.
I preferred the previous text for this section
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 sho
On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
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 that can be
>
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 e
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
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?
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 mentioni
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/*` f
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.
> I
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
Ben Finney writes ("Re: Removing duplication: Word lists of common words in
languages"):
> Ian Jackson writes:
> > I had roughly this question in 2013, and found the answer. Here is
> > probably the best starting point:
> >
> > http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-us
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
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 `debian/README
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 t
Package: wnpp
Severity: wishlist
Owner: Allen Riddell
* Package name: python-lda
Version : 0.3.2
Upstream Author : lda developers
* URL : https://pypi.python.org/pypi/lda
* License : MPL-2
Programming Lang: Python
Description : Topic modeling with late
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-oslo.concurrency
Version : 0.2.0
Upstream Author : OpenStack developers
* URL : https://github.com/openstack/oslo.concurrency
* License : Apache-2.0
Programming Lang: Python
Desc
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 serialize
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 peop
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-oslo.middleware
Version : 0.1.0
Upstream Author : OpenStack Developers
* URL : https://github.com/openstack/oslo.middleware
* License : Apache-2.0
Programming Lang: Python
Descri
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.
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 ba
-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 wrote:
>
>
>It is very sad to
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:
>
> htt
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 you
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
> bet
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 v
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,
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 http://dep.debi
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,
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
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? Wo
* Daniel Pocock , 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
better than people
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
On Wed, 12 Nov 2014 11:04:05 +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 t
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 a
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
"
2014-11-12 10:28 GMT+01:00 Raphael Hertzog :
> 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
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 UNSUBSCRIBE,
On Wed, Nov 12, 2014 at 10:02 AM, Raphael Hertzog 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 Ubuntu?)
>
> I
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 `/`. For example, a Debian
> maintainer
> Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag
> n
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 ano
[ 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 r
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
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
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg
* Package name: noggit
Version : 0.6
Upstream Author : Yonik Seeley
* URL : http://github.com/yonik/noggit
* License : Apache-2.0
Programming Lang: Java
Description : Fast streaming JSON parser for
Paul Wise 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
> > optio
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 a
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
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`, `debian/
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
--
https://githu
> "Jonathan" == Jonathan Dowland 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 that
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, em
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 UNSUBS
94 matches
Mail list logo
