On Wed 2020-03-11 10:55:57 +0100, Santiago Vila wrote: > On Tue, Mar 10, 2020 at 11:57:34PM +0100, Santiago Vila wrote: > >> * The fact that several consecutive Debian releases are folded into the >> same git commit. > > Most probably this is a consequence of snapshot.debian.org not > containing every release ever made in the past. I guess > snapshot.debian.org was bootstrapped with packages from the > stable releases so far (i.e. skipping intermediate versions).
yep, this is why, that's all i had to work from.
> I keep old releases and could probably construct a history line more
> accurate than the one reflected in the salsa repo you created.
> However, becoming an historian of my own packages is not right now
> a priority for me.
understood. If you've got that archive published someplace, i could
take it and curate it into a more detailed git repo than the one that
i've done here, but i also don't know how much bandwidth i have to spend
becoming a historian of someone else's packages when there's more
pressing work to do in debian looking forward as well as backward :)
> I wonder what are the common practices regarding this. I see that some
> people put packages in salsa without any history at all (debian-med
> comes to mind). But I also suppose that having the full history is
> nicer and desirable in a general sense (don't know how many people do
> it that way).
>
> Is this up to the maintainer?
yep, as usual in debian, i think it's entirely up to the maintainer.
There are some best practices developing (e.g. DEP-14) but in my
experience, people's git repositories are all over the place, and
historical data is quite often imported "uncleanly" for the sake of
expediency, so you can see a marked difference in the shape of the repo
between times *before* the import and going forward after the import.
> I believe your main goal is to have the package in salsa "in whatever form",
> and having the full history is a secondary goal which is just a nice
> thing or a bonus but not the main intent. Is this ok?
yep, that matches what i was trying to do, and if it's "not ok" then
there's a lot of "not ok" in debian :P
In practice, i think it's fine. certainly having a oddly-shaped history
under public revision control is better than not having any shape of
history in public revision control :)
and if someone gets inspired to redo the history later, it's not
inconceivable to rebase any future non-historical work on top of a
modified history (any signed tags or commits would break in such a
transfer, but you could always re-sign them as part of such a transplant
operation).
> So, I can think of several criteria to trim history a little bit and
> simplify our work. For example:
>
> * Starting the history at the first release for which I was the
> maintainer.
>
> * Starting the history at the first GPLed release (not every release
> was DFSG-free, and we were not strict at the time with that, I guess
> the package was on the verge of being moved to non-free, this is true
> for procmail, but I'm not completely sure about smartlist.
>
> * Starting the history only at the current oldoldstable, or whatever
> release is supported by the LTS team.
i understand all these options for ways to cull the history.
the option i chose for culling the history was:
* all the versions that are currently being published by the snapshots
service
which seems as good as any of the above to me. I certainly wouldn't
object if you wanted to make a different cut, but i'm unlikely to know
the details of that cut as well as you are.
Thanks for thinking this over with me, and thanks for all your work in
debian!
--dkg
signature.asc
Description: PGP signature
