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

Re: apt-listchanges cleanup



On Sat, Jul 31, 2021 at 10:34:14PM -0500, Brian Thompson wrote:
> A couple weeks ago, a new version of apt-listchanges made it into
> experimental (3.25): 
> https://tracker.debian.org/news/1244725/accepted-apt-listchanges-325-source-into-experimental/
> 
> On the Tracker site, apt-listchanges has some outstanding tasks, namely
> updating the Salsa repo with what is in the master FTP. See:
> - https://tracker.debian.org/pkg/apt-listchanges
> - https://qa.debian.org/cgi-bin/vcswatch?package=apt-listchanges

Have you seen my late reply to your last mail?
https://lists.debian.org/deity/2021/07/msg00039.html

I didn't CC you explicitly (I did now though) as that is against the
rules of the mailinglists – it is a bit surprising for the uninitiated
through: https://debian.org/MailingLists/#codeofconduct

The tracker page mainly noticed the same I did: The repository does not
have the 3.25 tag.


> The debian-sid branch is behind by two commits that were not made by
> myself.  Also, debian-experimental is behind on Salsa and needs to be

I guess I was a bit confused as I somehow saw commits from you which are
obviously not there… I guess I mixed it up with the repo you had before?

Anyway, I can give you access to debian/apt-listchanges on salsa (or any
other DD really, d-mentors@ has requests to that effect sometimes as
well). Just reply on list here with your salsa username and I will see
to it.


> updated with the most recent commits I made. Will these changes have to

I presume your changes are based on debian-sid branch, probably from
before Jelmer and his bot committed to it as well?

I guess I would merge my local changes to the debian-exp branch
(preferably --ff-only, but I am not sure if the two diverged) push that
(with tag) and then merge the debian-exp branch into debian-sid so that
a future next version has your 3.25 and Jelmers commits in a somewhat
reasonable flow and without rewriting history (and force pushing).


> wait (since testing is in a freeze, does that mean sid is frozen as
> well)?

The release team puts the suite testing codenamed bullseye into freeze,
so it can (soon) promote bullseye to be the suite "stable". Freeze means
that certain (additional) demands are imposed on packages to move from
the suite unstable to testing (individual packages can not move between
other suites at all, so no experimental to unstable for example).

So, unstable is technically not frozen at all. Many of the rules require
unstable to behave properly though, so in practice it feels like frozen:

Consider someone would find a release-critical bug in apt-listchanges
3.24 in testing. Someone (e.g. you) would need to provide a patch to fix
that bug and upload it to unstable – the changes you did in 3.25 or the
commits Jelmer made would be refused at this stage in the release
process. You would need to revert them and only upload a 3.24.1 fixing
exactly the release critical bug, not adding extra fluff (with
potentially new bugs). See the website of the Release team for details.

apt-listchanges is considered a key package btw. That is why
I recommended targeting experimental with 3.25 for now so that it would
still be easily possible to release a 3.24.1 if need be.



That all applies to the archive though. You can literally do whatever in
the version control system in salsa as they are largely unrelated.
The branch names are freely chosen and it seems a bit like everyone has
slightly different ideas.  There is a proposal for a standard layout
with DEP-14 [0] Jelmer was arguably following though.

What you might want to do though – depending on your liking – is fork
the debian/apt-listbugs repo into your personal namespace and prepare
your changes there and only move them to debian/apt-listbugs if they are
uploaded to the archive given a sponsor might request changes on your
first try. That might just be me through as I am kind of a neat freak
than it comes to version control histories… being bold and just
committing to the main repo like Jelmer is while the polar opposite
equally valid.


[0] https://dep-team.pages.debian.net/deps/dep14/

> What I'd like to do is:
> - Create a 3.24.1 release for debian-sid with the new commits

You mean Jelmers? No need to upload those alone in a new version, they
don't have any real practical effect anyway, just include them in
whatever your next release will be.

After the freeze you could e.g. upload a 3.25.1 to unstable.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: