Hello Jonas,
I don't wanted to start a discussion challenge that costs a lot of time on all sides and wasn't a big movement forward until now, at least for me. My last week of holidays is over now and I wont have that much time working further on this. I was hoping I can get updated that rather small and easy package localechooser the past week.
So I'd like to only give some partial notes and comments.
Am 08.10.21 um 11:13 schrieb Jonas Smedegaard:
I am happy if you find it straightforward. Personally I disagree, though - I find it more straightforward to do `git merge --no-ff 2.93` as step 3, and skip steps 4-5.
We will find for sure 3-5 other possible ways to reach the goal, and they all will have ups and down depending on the PoV each of us. We all have different workflows we learned and practice over the years and will mostly prefer the one we use for long times because we now it working. The user in the end doesn't cares much about how "his" package was build or derived, for me as an part time contributor it's important I can spend my time most efficiently.
I think others also find `git merge` more straightforward - I guess that's the reason they prefer that, and the reason we have the discussion about resulting (to me confusing/misleading) changelog structure at https://tracker.pureos.net/T1049
After reading this quite longer discussion from T1049 I still see no gain for me for doing something different than 'git merge' to manage upstream changes. It's possible yes, but I for my self wont be able to do this for time and complexity reasons e.g. for Thunderbird where I need to keep track of all possible releases right now (exp -> sid -> stable -> old-stable). Preparing and doing a Debian release is now almost work for about 8h including some testing, so I'm glad that git helps me if I do a 'git merge' into the next logical release and I mostly only need to reorder d/changelog.
...
The problem currently is that there are two master branches existing, the one within the localechooser tree and the one on the Debian upstream.
I see no problem there - perhaps I am missing some details?
My approach is to not checkout any Debian branches - and therefore it does not matter if Debian and PureOS use same name for some branch.
That's correct if you only work by merging tags. But does not really help to get and use a common practice that keeps the barrier low for newbies (like currently me) and maintenance time burden and complexity at a minimum if we do it differently all over. OTOH a name clashing wouldn't exist if name spaces would be used, And more, for me is working with (local) branches more intuitive than only working with tags. And of course I need some graphical tools like gitk, gitg to get an logical overview. Within Debian there are teams and packages that are using the upstream git tree instead of using gbp "only" for importing tarballs and managing Debian patches, there it's essential that different branch names are used. And we are now in a comparable situation I think.
In the end I (want to) see no difference if I work within a Debian packaging tree directly or in a PureOS tree, it's all just another fork I'm working in. Just that PureOS is here a fork of the Debian source, while Debian is technically also just a fork of upstream. Why should I (we) work differently then?
...
Regardless of my method not affected by potential branch name clash, I agree that we should embrace DEP14 and use branches `pureos/latest` and `upstream/latest` when it does not complicate our collaboration with upstream (I am not aware of any concrete problem, just mean to say that embracing DEP14 should be a "SHOULD" not "MUST" in policy lingo).
...
Sorry, I am not quite sure what you are saying above. It seems that what you describe as "small exception" is what I find an important distinction - and the very reason I described in detail my approach, and tried to provide reasons why.
We starting to go in circles, and we're back on the starting point...
So now after some rounds of discussion I see one main question were we should come to an common answer as this is the ground for potential further work from me.
What to do with git trees which currently don't use DEP14 for branch names?
My guess is that all participants agree that we want to use a "pureos/" prefix within PureOS related work as already pointed in T1049, the question to me is how to migrate the existing trees/repos?
My preference on doing that is currently to create the branch "pureos/latest" based on HEAD of (origin≙pureos) "master" with a deletion of the old master branch by the GitLab UI afterwards. Then adding and merging in the Debian/Salsa source (which might contain a branch named "master") with possible additional PureOS related commits on top.
For localechooser this would look like this:
https://source.puri.sm/pureos/core/localechooser-test/-/network/pureos%2Flat...
(To see where are caveats like required permissions I've setup the -test repo within /pureos/core/).
To get things done I'd like to postpone the topic 'git merge' vs. 'git rebase' into the future for now. Otherwise I fear we wont get any further.
...
https://source.puri.sm/pureos/packages/lollypop contains no local feature commits (i.e. no feature changes, only boilerplate changes to packaging metadata) so does not illustrate well how to best tackle package upgrades. What it does illustrate is that it didn't preserve earlier PureOS work - i.e. the work tracked at https://source.puri.sm/librem5-apps/lollypop
That is unfortunately correct. :( I wasn't aware that there was already a lollypop tree until now. Then we need to think about how get that split fixed.
https://source.puri.sm/sureos/packages/gnome-boxes illustrates how Chris at debian/3.27.92-1pureos2 created a feature change, and I hundreds of upstream commits later did _not_ do a `git merge` but instead started over (while preserving the old commits tied to their release tag) and cherry-picked the feature change into the fresh fork of upstream work.
As written above, I see no real gain in doing so.