Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Tweaking Kea development process proposal (Francis Dupont)
2. Re: Tweaking Kea development process proposal (Michal Nowikowski)
3. Re: Tweaking Kea development process proposal (Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Sun, 13 Oct 2019 17:23:02 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Tweaking Kea development process proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
How does this work with entries from before Gitlab? Should we split the
ChangeLog intp two parts?
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Mon, 14 Oct 2019 06:32:54 +0000 (UTC)
From: Michal Nowikowski <[email protected]>
To: Tomek Mrugalski <[email protected]>, [email protected]
Subject: Re: [kea-dev] Tweaking Kea development process proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello,
Re. 5: maybe split ChangeLog to more files, eg. one per stable release?
Regards,
Michal
----- Original Message -----
From: "Tomek Mrugalski" <[email protected]>
To: [email protected]
Sent: Sunday, October 13, 2019 12:38:17 PM
Subject: [kea-dev] Tweaking Kea development process proposal
We had a heated discussion in Stork about changelogs, commit logs and
branch names. There are couple process changes that we're going to do in
Stork. They also make sense in Kea, so I'd like to discuss them here.
Our gitlab howto was a bit dated anyway. I've cleaned up and updated the
gitlab-howto page. See here:
https://gitlab.isc.org/isc-projects/kea/wikis/Processes/gitlab-howto
1. The changelog entry will get simplified. We used to put GL issue #,
MR # and commit-id. All three are very similar in the sense that they
attempt to point to more information if the user wants to know more
about the actual code changes. Since you can get the MR# and the
commit-id from GL#, let's simplify the entries to just GL#.
1662. [bug] marcin
Prevent deadlock in the Kea DHCP servers caused by allocating
memory in the system signal handler. The issue was found on
CentOS 7.6, but could possibly affect Kea running on any other
OS.
(Gitlab #796)
The "Gitlab" string is necessary, because sometimes (very infrequently),
we handle changes coming from somewhere else (such as github).
2. Previously we expected the commit logs in git to start with
[GL#,!MR]. Getting the MR number was tricky, annoying and sometimes even
impossible (e.g. if you did some experiments and were not even sure if
the code should be merged anywhere). We'll use [GL#] from now on. This
is also something that can be automated with precommit hook in git. But
also see point 3 below.
3. Every branch name must start with an issue number, e.g.
123-my-awesome-fix. Yes, even if you do some experiment on the side.
Opening an issue takes 30 seconds. This is for the automated hook in #2
above to work. There's also very good practical reason for this. If you
use bash completion, you can type git checkout 123 and hit tab, so bash
will autocomplete your branch name.
4. Added clarification when it's necessary to add a changelog entry.
See:
https://gitlab.isc.org/isc-projects/kea/wikis/Processes/gitlab-howto#changelog
We can also consider the following:
5. We can rename Changelog to Changelog.md, so the Issue number will be
displayed as clickable links. You can look at this proposal here:
https://gitlab.isc.org/isc-projects/kea/blob/951-changelog-markdown/ChangeLog.md
THe benefit is automated links, the downside is that gitlab needs a
while to parse 400KB of markdown. I'm not so sure about 5.
Thoughts? Comments?
Tomek
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 3
Date: Mon, 14 Oct 2019 06:55:21 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Tweaking Kea development process proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Re: 5
ChangeLog as plain text means viewing it is always possible in a command
line environment with nothing
special.? I don't see having automated links to be all that big of a help.
I am not crazy about a ChangeLog per stable release.? There are
frequently times when working on ISC DHCP
it is necessary to try and find possible changes that may have
introduced an issue and sometimes requires
looking years backwards.? The RELNOTES file, which is ISC DHCP's version
of "ChangeLog" provides an
invaluable resource for that.
I realize that not everyone thinks this sort of "what happened in days
of yore" ability is important but
it is.? So if it were up to me, I would leave ChangeLog as plain text
and with a single file.? This is
of course only my own personal opinion.
Thomas
On 10/14/19 2:32 AM, Michal Nowikowski wrote:
> Hello,
>
> Re. 5: maybe split ChangeLog to more files, eg. one per stable release?
>
> Regards,
> Michal
>
> ----- Original Message -----
> From: "Tomek Mrugalski" <[email protected]>
> To: [email protected]
> Sent: Sunday, October 13, 2019 12:38:17 PM
> Subject: [kea-dev] Tweaking Kea development process proposal
>
> We had a heated discussion in Stork about changelogs, commit logs and
> branch names. There are couple process changes that we're going to do in
> Stork. They also make sense in Kea, so I'd like to discuss them here.
>
> Our gitlab howto was a bit dated anyway. I've cleaned up and updated the
> gitlab-howto page. See here:
> https://gitlab.isc.org/isc-projects/kea/wikis/Processes/gitlab-howto
>
> 1. The changelog entry will get simplified. We used to put GL issue #,
> MR # and commit-id. All three are very similar in the sense that they
> attempt to point to more information if the user wants to know more
> about the actual code changes. Since you can get the MR# and the
> commit-id from GL#, let's simplify the entries to just GL#.
>
> 1662. [bug] marcin
> Prevent deadlock in the Kea DHCP servers caused by allocating
> memory in the system signal handler. The issue was found on
> CentOS 7.6, but could possibly affect Kea running on any other
> OS.
> (Gitlab #796)
>
> The "Gitlab" string is necessary, because sometimes (very infrequently),
> we handle changes coming from somewhere else (such as github).
>
> 2. Previously we expected the commit logs in git to start with
> [GL#,!MR]. Getting the MR number was tricky, annoying and sometimes even
> impossible (e.g. if you did some experiments and were not even sure if
> the code should be merged anywhere). We'll use [GL#] from now on. This
> is also something that can be automated with precommit hook in git. But
> also see point 3 below.
>
> 3. Every branch name must start with an issue number, e.g.
> 123-my-awesome-fix. Yes, even if you do some experiment on the side.
> Opening an issue takes 30 seconds. This is for the automated hook in #2
> above to work. There's also very good practical reason for this. If you
> use bash completion, you can type git checkout 123 and hit tab, so bash
> will autocomplete your branch name.
>
> 4. Added clarification when it's necessary to add a changelog entry.
> See:
> https://gitlab.isc.org/isc-projects/kea/wikis/Processes/gitlab-howto#changelog
>
> We can also consider the following:
>
> 5. We can rename Changelog to Changelog.md, so the Issue number will be
> displayed as clickable links. You can look at this proposal here:
> https://gitlab.isc.org/isc-projects/kea/blob/951-changelog-markdown/ChangeLog.md
>
> THe benefit is automated links, the downside is that gitlab needs a
> while to parse 400KB of markdown. I'm not so sure about 5.
>
> Thoughts? Comments?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 64, Issue 2
**************************************
