Hello,
Thank you for the feedback, Simon.
I tried to incorporate what you said while avoiding talking about the
namespace pairs, for the sake of readability. Further, I shortened
"upstream version without the epoch" to "upstream version" because the
epoch is a Debian thing.
Seeking seconds:
>
Hello Adrian,
Thank you for your continued effort to get this bug resolved.
On Sat, Mar 10 2018, Adrian Bunk wrote:
>> Please expand on why you think this is the way we have to proceed.
>
> you skipped the part of my email with the explanation:
>
> with such a piecemeal approach
> we risk fr
On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
>
> Thank you for your continued effort to get this bug resolved.
>
> On Sat, Mar 10 2018, Adrian Bunk wrote:
>
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my
Hello,
On Wed, Apr 04 2018, Adrian Bunk wrote:
> This ensures that policy will always be horribly outdated.
Policy is meant to lag behind practice. One of the reasons for this is
that it ensures that no-one feels they have to update Policy before
innovating.
The extent to which it lags is a fu
Hello Ian,
On Fri, Feb 23 2018, Ian Jackson wrote:
> We had another thread on debian-devel recently, in which it once again
> became evident that epochs are misunderstood. Epoch bumps should be
> rare and there are often better solutions. I suggest that we should
> ask people to consult debian-
Hello,
On Mon, Feb 26 2018, Mattia Rizzolo wrote:
> This needs to be reworded. "the +really convention" is probably not
> really policy material (feels more like devref's) and therfore probably
> not mentioned here.
I disagree. Policy often describes conventions; in particular,
conventions tha
6 matches
Mail list logo
