[PureOS] Updating localechooser in landing/byzantium

[Jonas Smedegaard]

Quoting Carsten Schoenert (2021-10-08 08:54:58)
> > Personally¹ I do "upstream first" package maintenance by treating 
> > upstream packaging branch as the _only_ baseline, rebasing PureOS 
> > commits on top of that when needing to realign with Debian.
> > 
> > I would therefore start over from scratch, starting from upstream 
> > Debian git repo.  Something like this:
> > 
> >   1. fetch upstream Debian packaging project:
> > 
> >       debcheckout localechooser
> > 
> >      ...or if that fails then locate git and do it manually:
> > 
> >       git clone https://salsa.debian.org/installer-team/localechooser.git
> > 
> >   2. include previous work as remote branch _without_ merging:
> > 
> >       git remote add pureos_old https://source.puri.sm/pureos/core/localechooser.git
> >       git fetch pureos_old
> > 
> >   3. rewind to closest possible upstream commit before or at their 
> >      latest release:
> > 
> >       git reset --hard 2.93
> > 
> >   4. auto-generate² boilerplate forking commits:
> > 
> >       ~/projects/PURISM/FEATURE/package/bin/fork_at_pureos_for_byzantium.sh
> > 
> >   5. cherry-pick non-boilerplate commit from previous work:
> > 
> >       git cherry-pick 87c1922826060102a2d5a9abe968dc657630fab9
> > 
> >   6. finalize¹ and release:
> > 
> >       dch --local ~pureos .
> >       gbp dch -a
> >       DEBEMAIL="jonas.smedegaard at puri.sm" dch --vendor pureos --distribution byzantium --release
> >       git commit -m "prepare for release: update changelog" -a
> 
> That's the obvious and a straight forwarded way.

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.

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


> I was thinking about how we can keep the existing repository and by a 
> bit more manual work to get to the same state in the end. I think it's 
> doable, but with some manual tweaking required within the GitLab UI on 
> source.p.s.
> 
> 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.

Personally I use `tig --all` to browse both local and remote branches 
together, to locate a commit to rebase from or to cherry-pick.  Before I 
learned about tig I used `git log -p <branch>` for each specific branch 
(local or remote) I wanted to investigate.

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).


> The following required steps should be obvious, keep track the Debian 
> sources and do in the end the same as lollypop and seahorse was done, 
> as Guido already mentioned. With the the small exception that I would 
> merge 2.9.3 into the now existing pureos/latest branch. I've all this 
> done locally already.

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.

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

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.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20211008/35f701f8/attachment.sig>