[kea-dev] Tweaking Kea development process proposal

[Thomas Markwalder]

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" <tomasz at isc.org>
> To: kea-dev at lists.isc.org
> 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
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev