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

Re: Reducing allowed Vcs for packaging?

On Sunday, 26 February 2023 22:38:51 CET Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> > On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> >...
> >
> > > For anything in Debian, the package sources in Debian would not
> > > disappear when a repository (or salsa) disappears.
> > 
> > Question as I don't know: is that only the package change that gets
> > uploaded to the Debian archive, or is there also a place where the (git)
> > history of the changes leading up to a new upload gets stored?
> > 
> > To use an analogy: I'd like that not only the 'destination' is preserved,
> > but also the lead up to the destination.
> What goes into the Debian archive is based on tarballs and quilt patches.
> Nothing is stored there except the files you upload.

Thanks, I thought/'feared' so.

> But what do you expect to get from the git history?
> There is no requirement that any history in addition to what is in
> the Debian archive exists at all, or any guarantee that what is in
> some git tree somewhere is actually the same as what is in the
> Debian archive. And git history might just be one commit per upload.
> I would rather like to see people write useful changelog entries
> that will still be useful in 25 years instead of
>   * New upstream version (Closes: #1234567, #1234568, #1234569, ...
> or
>   * Add R³
> than hoping that git metadata would contain anything more useful
> than that for such packages.

What you described and what I mostly see on changelog entries is:
What was changed.

What I rarely see is *why*

I'm a big proponent of the following git commit structure, which then 
automatically becomes the git history:
primary commit msg: what has changed
secondary commit msg: why that change was made including context, 
deliberations made during that change/commit and alternative solutions 
considered and why the committer didn't choose for those.

The secondary commit msg can be LONG and I like that as it also shows the 
author/committer pays attention to such things.
The (upstream) kernel commit history is a treasure trove of excellent commit 

The reason that I'm such a proponent of that is that 3 weeks or 3 months from 
now, there's a reasonable chance that you (the author/committer) does no 
longer remember the details of that commit.
In 3+ years that will be close to 0.
AFAIK actual mind reading does not exist, so someone else surely wouldn't 

I've already encountered several cases where the commit was 10+ years old and 
the commit msg what "Disable setting X" and looking at the diff, I can see the 
X was indeed disabled. But nothing more.
But now I want to enable setting X. But I have no context to know why that 
would be a bad idea, or actually a good idea *now*, or what will break as a 
consequence of my enabling X. All I can do is enable X and keep an eye out for 
bug reports.

I think that's what you want to achieve with 'better' changelogs is something 
similar. I think the git commits are a better place as it's easier to make 
finer grained distinctions and it's more directly linked to the changes.

FTR: I don't *expect* to see those extended commit messages in those old SVN 
repos, but I do hope I can at least derive _some_ information from the various 
commits itself.

When I was using my own SVN repo I started doing that and I know that I 
benefited from that a couple of months later. I should have a backup of that 
somewhere and I'm quite curious if I restore it (and convert it to git) if I 
can still construct enough detail/history/context from those commit msgs.
(As described in the debian-qa ML post, that repo should be 15+ y/o ?)


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: