[Tails-dev] [review'n'merge:1.4] feature/8617-delete-obsolet…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: tails-dev
New-Topics: [Tails-dev] Heads up! code contributors -> Git submodules [Was: [review'n'merge:1.4] feature/8617-delete-obsolete-Git-branches ...]
Subject: [Tails-dev] [review'n'merge:1.4] feature/8617-delete-obsolete-Git-branches (introduces Git submodules usage!)
Hi,

please review'n'merge feature/8617-delete-obsolete-Git-branches into
testing and devel. It should have no effect at all on what ends up in
the ISO: it merely adds some code that will allow the RM to delete
merged Git branches once 1.4 is out.

Some notes for the reviewer, that may be of some interest to anyone
who's working on Tails code:

1. This branch depends on the shiny new Tails Python 3 library:
https://git-tails.immerda.ch/pythonlib (the tailslib.jenkins module
isn't used though, so you can skip reviewing that one).
Code reviews by experiences Python developers would be much
welcome, as that library was developed by people who don't qualify
as Python experts.

2. This branch introduces the use of... Git submodules! I have two
   reasons to go this way:
   * Git submodules are the "natural" way to express commit-level
     dependencies between several repositories; that's exactly what we
     need here;
   * we've been thinking forever of using Git submodules for more
     critical parts of our code, e.g. for tracking our custom
     additional .deb's from our main Git repo (#7036 and the
     corresponding blueprint); the web has plenty to tell about Git
     submodules limitations and problems, and this migration is a bit
     scary in general, that's why we've not been bold enough to try it
     out yet. Also, it might be that Jenkins doesn't support them
     well. So, I figured that the best way was to simply start using
     them for a use case that doesn't impact the ISO build system, and
     in practice should only impact the release managers: this way,
     some of us will get their hands dirty, learn a bit how the beast
     behaves in practice, and identify potential issues. From there,
     we can decide to use Git submodules more, or to look
     for alternatives.


3. From (2), it follows that we encode the URL of the submodule(s) in
the main Git repo. I've decided to use the read-only public
https:// URL. And then, developers with commit credentials will
want to:

     git config --global url.tails@???:.insteadOf \
        https://git-tails.immerda.ch/


... if they want push to the submodule's remote. The alternative
would have been to do the opposite (encoding the ssh:// URL), but
I figured it would be nicer to newcomers if they don't have to go
through additional steps to get a working Tails Git repo.
And besides, we now have more contributors without commit bit
than with.

I realize some of these changes may not be consensual, that's why
I didn't merge the proposed branch into experimental yet (if people
don't want to use submodules at all, let's not force them to without
some room for discussion).

Cheers,
--
intrigeri