-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Mar 09, 2016 at 11:37:12AM +0100, IOhannes m zmölnig (Debian/GNU) wrote:
> i think that §4.13 does not cover the original issue of jonas at all, as
> it's about something different: using convenience copies instead of the
> system provided
Quoting IOhannes m zmölnig (Debian/GNU) (2016-03-09 11:37:12)
> On 2016-03-08 19:23, Bas Wijnen wrote:
>> On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
Oh - I just discovered that this _is_ covered by Policy §4.13
already.
>> Reading that again, I see that it says
On 2016-03-08 19:23, Bas Wijnen wrote:
> On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
>> > Oh - I just discovered that this _is_ covered by Policy §4.13 already.
> Reading that again, I see that it says code copies are acceptable if the code
> is meant to be used that way
Quoting Bas Wijnen (2016-03-08 19:23:18)
> On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
>> Oh - I just discovered that this _is_ covered by Policy §4.13
>> already.
>
> Reading that again, I see that it says code copies are acceptable if
> the code is meant to be used that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 08, 2016 at 02:14:10PM +, Jonathan Dowland wrote:
> On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> > I personally feel it is a bug to not track the true upstream of a
> > project, but that seems not part of our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
> Oh - I just discovered that this _is_ covered by Policy §4.13 already.
Reading that again, I see that it says code copies are acceptable if the code
is meant to be used that way
On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> I personally feel it is a bug to not track the true upstream of a
> project, but that seems not part of our Policy. Should I respect fellow
> package maintainers prioritizing convenience over elegance, or insist
> that we
Quoting Jonas Smedegaard (2016-02-27 13:08:37)
>> 2. Needless forking is bad. There is no consent on what is
>>"needless" though. My point is that having multiple copies of a
>>thing that are all treated as source leads to problems. In
>>Debian, we recognize that and one effect of
On Monday 07 March 2016 03:59 PM, Jonas Smedegaard wrote:
> Thanks for your clarifications - they seem to confirm that you were,
> and still intend to be, pragmatic - e.g. track the real upstream only
> when strongly encouraged to do so.
>
I don't think there is much benefit to enforce this
Hi Praveen,
Quoting Pirate Praveen (2016-03-07 10:27:31)
> On Saturday 27 February 2016 12:29 AM, Jonas Smedegaard wrote:
>> ¹ bug#809977 requests adding node-handlebars to src:libjs-handlebars
>> (to cover not only browser but also server-side use), but package
>> maintainer chose to instead
On Saturday 27 February 2016 12:29 AM, Jonas Smedegaard wrote:
> ¹ bug#809977 requests adding node-handlebars to src:libjs-handlebars (to
> cover not only browser but also server-side use), but package maintainer
> chose to instead package libjs-handlebars from a Ruby bundling
> (re)source (see
On Mon, Feb 29, 2016 at 10:39:26AM +0100, Jonas Smedegaard wrote:
> Quoting Paul Wise (2016-02-29 04:30:02)
> > On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote:
> >
> >> IMO both in this specific case, and in the general case, the correct
> >> technical decision is to track the actual
Quoting Paul Wise (2016-02-29 04:30:02)
> On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote:
>
>> IMO both in this specific case, and in the general case, the correct
>> technical decision is to track the actual upstream as a proper
>> Javascript package (supporting both browser usage and
On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote:
> IMO both in this specific case, and in the general case, the correct
> technical decision is to track the actual upstream as a proper
> Javascript package (supporting both browser usage and NodeJS, if it
> makes sense), and make the
On Fri, Feb 26, 2016 at 10:37:48PM +0100, Jonas Smedegaard wrote:
> I do recall our conversation at Debconf. That was however, I believe,
> an agreement only between teams. I believe we cannot impose team rules
> on Debian as a whole: I can file a _whishlist_ bugreport against a
> package
Quoting Bas Wijnen (2016-02-26 20:16:32)
> On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
>> Do we favor tracking the true upstreams when packaging for Debian?
>
> There was some discussion about this on the list recently, but this is
> a question that didn't really come up,
Hi Antonio,
Quoting Antonio Terceiro (2016-02-26 21:47:03)
> On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
>> Do we favor tracking the true upstreams when packaging for Debian?
>>
>> Concretely I need¹ a javascript library for server-side use, but the
>> maintainer considers
On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> Hi,
>
> Do we favor tracking the true upstreams when packaging for Debian?
>
> Concretely I need¹ a javascript library for server-side use, but the
> maintainer considers it adequate² to package that project only
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote:
> Do we favor tracking the true upstreams when packaging for Debian?
There was some discussion about this on the list recently, but this is a
question that didn't really come up,
Hi,
Do we favor tracking the true upstreams when packaging for Debian?
Concretely I need¹ a javascript library for server-side use, but the
maintainer considers it adequate² to package that project only
browser-optimized.
I personally feel it is a bug to not track the true upstream of a
20 matches
Mail list logo
