> 3. Feature branches are expected to add a file to upgrading/next that
> explains their upgrade requirements.
I'm wondering whether we would want this file to exist even if the feature has
no upgrade requirements, and maybe just say "no upgrade requirements" -- so
that the difference between "
In our last dev call, we said that we'd like to start keeping notes, during
vX.{odd} versions about what you'll need to do to upgrade to the next vX.{even}
version. This is important! We expect most people only run stable versions,
and will want to know what kind of upgrade process might exist
On 06/01/2021 23:15, Дилян Палаузов wrote:
Hello Matt,
I personally cannot apply for US jails, as US law does not apply to
me. If some administrative work shall be done because of US laws, then
the work shall only be done by those under US law.
Some years ago I wanted to contribute 10 lines
--On Thursday, January 7, 2021 1:15 AM +0200 Дилян Палаузов
wrote:
Hello Matt,
I personally cannot apply for US jails, as US law does not apply to me.
If some administrative work shall be done because of US laws, then the
work shall only be done by those under US law.
Other countries ha
Hello Matt,
I personally cannot apply for US jails, as US law does not apply to me. If some
administrative work shall be done because of US laws, then the work shall only
be done by those under US law.
Some years ago I wanted to contribute 10 lines to GNU. I was told to print,
sign, scan and
On 06/01/2021 21:55, Дилян Палаузов wrote:
Hello,
my question was, what will the bad consequences be, if this is done
implicitly. The answer was that it cannot be done implicitly.
One possible reading is, that nobody knows what the negative
consequences could be and the hypothetical negative
Hello,
my question was, what will the bad consequences be, if this is done implicitly.
The answer was that it cannot be done implicitly.
One possible reading is, that nobody knows what the negative consequences could
be and the hypothetical negative consequences are just avoided when every hum
On 06/01/2021 20:37, Quanah Gibson-Mount wrote:
--On Wednesday, January 6, 2021 10:31 PM +0200 Дилян Палаузов
wrote:
Hello Quanah,
what will happen if all these things (like releasing rights) are done
implicitly, rather than explicitly? How bad can such an idea be?
It can't be done impl
--On Wednesday, January 6, 2021 10:31 PM +0200 Дилян Палаузов
wrote:
Hello Quanah,
what will happen if all these things (like releasing rights) are done
implicitly, rather than explicitly? How bad can such an idea be?
It can't be done implicitly. The contributor must explicitly transfe
Hello Quanah,
what will happen if all these things (like releasing rights) are done
implicitly, rather than explicitly? How bad can such an idea be?
Greetings
Дилян
Am 6. Januar 2021 21:37:03 OEZ schrieb Quanah Gibson-Mount :
>
>
>--On Wednesday, January 6, 2021 9:01 PM +0200 Дилян Палаузов
--On Wednesday, January 6, 2021 9:01 PM +0200 Дилян Палаузов
wrote:
Rather than requesting explicit actions, I would prefer something
implicit. E.g. creating a LICENSE file, that acts as "GENERAL TERMS":
once you contribute, you agree implicitly to the general terms.
It doesn't work tha
Hello,
my understanding is, that the Cyrus SASL code is currently more or less
owned by CMU and the question is how to amend the code, while it
belongs to CMU. Mails in the past left the CMU's opinion on this
unclear and I do not see how the text below addresses these.
Rather than requesting exp
Ken Murchison wrote:
> I'm not a legal scholar, but this looks good to me.
It's pretty much a copy/paste of what we've used in the OpenLDAP Project
for ... ages. Hasn't ever led to any legal challenges, afaik.
>
> On 12/10/20 5:02 PM, Quanah Gibson-Mount wrote:
>> Here's a draft of an IPR notice
13 matches
Mail list logo
