Re: Ideas for better development processes when maintaining hundreds of packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 28, 2020 at 8:59 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>
> On Tue, Jan 28, 2020 at 02:51:28PM +0100, Florian Weimer wrote:
> > * Pierre-Yves Chibon:
> >
> > >> Sorry for being unclear.  The spec file in dist-git would still show
> > >> some (older) version of the %changelog entries under this model.
> > >>
> > >> The corrections would update the %changelog with all the historic
> > >> entries.  Since auto-generation stops at this commit, the new generated
> > >> %changelog will include the fixed entries.
> > >>
> > >> This would also avoid the need for a new knob to adjust how far back the
> > >> %changelog generation goes.
> > >
> > > Let me rephrase to see if I understand correctly.
> > > The changelog would be something like:
> > > ``
> > > %changelog
> > > %generate_changelog
> > >
> > > <The changelog up to the point the packager opted to use the macro above>
> > > ``
> > >
> > > This way we don't need to generate the old entries, we can just focus on the
> > > commits once the packager has opted in and not look at the old commits in the
> > > git history.
> > >
> > > Is that what you were thinking?
> >
> > Yes, but the generation would not stop when %generate_changelog was
> > added, but when the last edit below %changelog was made.
> >
> > Does this make sense?  Sorry if I'm not explaining this properly.
>
> I think I understand, by going up until the time the changelog was last touched
> (be that the macro or something else), we give an easy way to edit it.
>
> We would also need to have fepdkg generate-changelog to help with this.
>

This is pretty similar to how it works in Mageia, actually. In the
Mageia workflow, changelog entries are managed manually until it is
imported into our Dist-SVN. The changelog section is stripped and
split into a separate file in a separate folder in the SVN tree (which
is the equivalent of an orphan branch) and appended after the
VCS-based changelog on package builds.

This can be viewed locally as well, like so (example from
python-distro in Mageia):

$ mgarepo rpmlog -o python-distro

<snip for brevity>

* Thu Sep 20 2018 Sysadmin Bot <umeabot@xxxxxxxxxx> 1.0.2-7.mga7
+ Revision: 1288676
- Mageia 7 Mass Rebuild

* Sat Aug 05 2017 Pascal Terjan <pterjan@xxxxxxxxxx> 1.0.2-6.mga7
+ Revision: 1135369
- Rebuild for python 3.6

* Thu Mar 16 2017 Neal Gompa <ngompa@xxxxxxxxxx> 1.0.2-5.mga6
+ Revision: 1093149
- Port to Mageia
- imported package python-distro

* Sat Feb 11 2017 Fedora Release Engineering
<releng@xxxxxxxxxxxxxxxxx> - 1.0.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild

* Tue Jan 24 2017 Miroslav Suchý <msuchy@xxxxxxxxxx> 1.0.2-3
- typo in license macro

* Tue Jan 24 2017 Miroslav Suchý <msuchy@xxxxxxxxxx> 1.0.2-2
- add license macro for el6

<snip for brevity>

You can see from the above example where the generated / manual
changelog split occurs.

mgarepo is packaged in Fedora and you can play with this to see how it works. :)

-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux