Re: [Netatalk-admins] Planning the next round of releases

[Daniel M. <mar...@gm...>]

Found a temporary hotfix until I figure out how to properly modernize
configure.ac
- https://github.com/Netatalk/netatalk/pull/330

The good news is that since we have 'make check' running in github CI,
a breakage such as this will be caught early in the future. :)

On Thu, Apr 27, 2023 at 10:03 PM Daniel Markstedt <mar...@gm...> wrote:
>
> the admins ML had inadvertently fallen of the recipient list
>
> On Thu, Apr 27, 2023 at 10:02 PM Daniel Markstedt <mar...@gm...> wrote:
> >
> > > That's how I used to do it in the past as well. Plus requiring a
> > > bugreport or github issue associated with changes targetted at a
> > > release. Ideally requiring commits to include a reference to the issue
> > > link in the commit message.
> >
> > Yes, I'll consider reintroducing a bit more structure moving forward.
> > I can see how it helps when managing the changeset for patch releases.
> >
> > Anyhow, I've prepared a local branch with cherry picked commits for
> > the 3.1.15 release.
> > However make distcheck is failing so I need to dig into what's going on.
> > Seems to be the same issue as https://github.com/Netatalk/netatalk/issues/313
> >
> > make[4]: *** No rule to make target 'test-afp_dsi.o', needed by
> > 'afp_dtrace.o'.  Stop.
> > make[4]: Leaving directory
> > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test/afpd'
> > make[3]: *** [Makefile:1751: check-am] Error 2
> > make[3]: Leaving directory
> > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test/afpd'
> > make[2]: *** [Makefile:472: check-recursive] Error 1
> > make[2]: Leaving directory
> > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test'
> > make[1]: *** [Makefile:531: check-recursive] Error 1
> > make[1]: Leaving directory '/home/dmark/netatalk/netatalk-3.1.15/_build/sub'
> > make: *** [Makefile:748: distcheck] Error 1
> >
> > On Thu, Apr 27, 2023 at 10:13 AM Ralph Boehme <sl...@sa...> wrote:
> > >
> > > On 4/27/23 10:48, Daniel Markstedt wrote:
> > > > I tried that and ended up dealing with never ending merge conflicts of
> > > > 10+ year old NEWS and VERSION updates for some reason.
> > > >
> > > > Should I be doing a different command than "git rebase main" from the
> > > > 3-1 branch?
> > >
> > > $ git checkout main
> > > $ git rebase -i branch-netatalk3-1
> > >
> > > ...and in the editor remove all commits from master you don't want, only
> > > keeping the changes you want in the 3-1 branch.
> > >
> > > >> Otherwise, if you want to rethink our branching and release strategy,
> > > >> the way we do it in Samba is explicit cherry-picking from master to the
> > > >> release branches for changes that should be part of a release.
> > > >
> > > > Yeah I may go ahead and do the cherry-pick approach this time...
> > >
> > > That's how I used to do it in the past as well. Plus requiring a
> > > bugreport or github issue associated with changes targetted at a
> > > release. Ideally requiring commits to include a reference to the issue
> > > link in the commit message.
> > >