After a week which mostly has consumed all my energy for $dayjob I'm now looking again into solving the original issue.
Am 09.10.21 um 17:50 schrieb Jonas Smedegaard: ...
We can preserve that history in the pureos/packages/lollypop repo need be or just leave it as is and use that fork in unlikely case we need updates for amber-phone. Both works for me.
That particular work of mine is not important for me that we preserve.
If topic of this conversation is _simplest_ practice then let's just throw away historic git repos.
The lollypop repos are bit out of scope of the original reason for this discussion ... to me it's mostly helpful if I can follow not only a recent development but also past development (if it's not done for pre sarge :P ). For sure we can combine the two trees into one were all the PureOS related modification are visible. This would require further work of course.
So a compromise from a POV of needed effort for me would be to keep the things how they are right now and maybe through away the old amber-phone-stuff after amber has becoming unsupported. If I'm feeling boring I can cherry-pick (or someone other) the old changes into the current most recent lollypop repo so the old tree could be removed earlier.
I pointed to that historic git repo because a) it was unclear to me what Carsten wanted to say (he also referenced missing posts by Guido still unavailable to me¹), and b) I mistakenly focused on finding _best_ practice.
O.k. I might have not made it fully clear what my objection was.
I'd like to avoid to do work that is in my eyes more error prone than the workflow I use for several years now if I do Debian packaging and I've also have seen within a lot of other packages by developers which I not know directly or have spoken too except by some email exchange maybe.
And I'd like to easy see what happen in the past within one or more packaging (git) trees. That's the main reason why I've suggest the renaming / migration of the current existing packaging tree for localechooser together with a pull in of the tree from Salsa. It's of also possible to start from scratch and cherry-pick the existing commits from the current tree.
But both ways require additional extra intrusive action on source.p.s. As I'm not able to do this without some help from users who are able to do this (nor want to do this without an acknowledge from others) we need to come to an agreement how we all can be happy.
@Guido @Jonas @Matthias If you think I tend to start more work than needed then it's best that a counter example would be done which I'm happily adopt for other packages. I looked into some repositories now already, but it's still a bit hard for me to get a feeling how derived packages get handled best here as I'm only able to look at things for a few hours a week.