Moving default branch after project creation

[Julian Gilbey]

Hi, I've recently created
https://salsa.debian.org/python-team/packages/psrecord following
previous ITP. The main branch was set to main and I'd like to move it
to DEP compliant debian/master and delete the main branch. 

The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
currently reads:

In Debian this means that uploads to unstable and experimental
should be prepared either in the debian/latest branch or
respectively in the debian/unstable and debian/experimental
branches.

I'm not sure where you got debian/master from?

(Maybe I screwed up by forgetting to uncheck the Readme.md first commit
?)
I cannot delete the default branch as expected, but Salsa doesn't let
me move it to debian/master either. I think I don't have the required
permissions.
remote: GitLab: The default branch of a project cannot be deleted.
To salsa.debian.org:python-team/packages/psrecord.git
! [remote rejected] main (pre-receive hook declined)
error: failed to push some refs to 'salsa.debian.org:python-
team/packages/psrecord.git'

Have you tried using the web interface to change the default?
(Settings > Repository) Create a new branch called debian/latest,
branched from master, then set the default branch to debian/latest
(and perhaps unprotect the master branch on the same page).

Best wishes,

Julian

[Nicholas D Steeves]

Post by Julian Gilbey

Hi, I've recently created
https://salsa.debian.org/python-team/packages/psrecord following
previous ITP. The main branch was set to main and I'd like to move it
to DEP compliant debian/master and delete the main branch. 

The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
In Debian this means that uploads to unstable and experimental
should be prepared either in the debian/latest branch or
respectively in the debian/unstable and debian/experimental
branches.
I'm not sure where you got debian/master from?

FYI debian/master was DEP14:

Changes
2014-11-05: Initial draft by Raphaël Hertzog.
2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson.
2020-11-29:
* Replace <vendor>/master with <vendor>/latest
* Recommend <vendor>/<suite> over <vendor>/<codename> for the devel branch
* For native packages, require the default branch to be a devel branch
* Minor typo fixes and cosmetic changes
* Promote DEP to State: CANDIDATE
Last edited Fri, 08 Mar 2024 12:33:22 +0000
https://dep-team.pages.debian.net/deps/dep14/

It's certain that there are many packages that follow DEP14 DRAFT rather
than CANDIDATE. An alternative interpretation is that DEP14 strong
recommends (ie "should use", "should be", "we recommend")
<vendor>/latest rather than <vendor>/master. Thus, <vendor>/master is
arguably still more DEP14 than not. We've also seen the proliferation
of <vendor>/main development branches that fulfil all of the technical
objectives of DEP14, and I would consider them to also be DEP14.

As an aside, I'm curious what the undocumented 2024 edit was.

Best,
Nicholas

[Carsten Schoenert]

Post by Julian Gilbey
The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
In Debian this means that uploads to unstable and experimental
should be prepared either in the debian/latest branch or
respectively in the debian/unstable and debian/experimental
branches.
I'm not sure where you got debian/master from?

From the Team Policy?

https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names

[Julian Gilbey]

Post by Carsten Schoenert

Post by Julian Gilbey
The candidate DEP-14 (https://dep-team.pages.debian.net/deps/dep14/)
In Debian this means that uploads to unstable and experimental
should be prepared either in the debian/latest branch or
respectively in the debian/unstable and debian/experimental
branches.
I'm not sure where you got debian/master from?

From the Team Policy?
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names

The OP specifically said they got it from DEP-14. Thanks also to
Nicholas for reminding me of the DEP-14 history!

Best wishes,

Julian

[Carsten Schoenert]

Post by Julian Gilbey
The OP specifically said they got it from DEP-14. Thanks also to
Nicholas for reminding me of the DEP-14 history!

I don't see what makes the difference in the end?

There is a DPT policy that enforces to usage of the branch name
debian/master for working on versions intended for unstable/sid.

Alexandru has permissions of the group Developer according to the
members list overview. It might be that this membership is restricted to
not being able to change the default branch. I haven't looked deeper
into this.

The current structure of the tree is wrong to me or at least contains a
useless branch.

Post by Julian Gilbey
$ git logg
* commit 4c0b559c9f60321be2fa412d73555ab38c517f16 (origin/pristine-tar)
Date: Wed Aug 7 19:11:03 2024 +0300
pristine-tar data for psrecord_1.4.orig.tar.gz
* commit 1443d1a19aeed367f2f2131757f01e2b9eafcfb4 (tag: upstream/1.4, origin/upstream, origin/debian/master)
| Date: Wed Aug 7 18:46:41 2024 +0300
|
| New upstream version 1.4
|
* commit 4c41bddf5c750a5c694aaba42c8252b444856ff7 (HEAD -> main, origin/main, origin/HEAD)
Date: Wed Aug 7 15:21:38 2024 +0000
Initial commit

There is the branch 'main' which contains just one file 'Readme.md'.

That one single commit is the parent for the two branches 'upstream' and
'debian/master' which includes the upstream source I guess as there is
also the tag upstream/1.4.

@Alexandru
For starting a packaging the git tree on Salsa is quite the last thing
you need to deal with (except you need a repo quite early in case of
needed and wanted collaboration with others).

I guess you did something like this at the start, if not you could do it
this way.

$ # get the upstream tarball e.g. into ~/Downloads
$ mkdir python-psrecord
$ cd python-psrecord
$ $ git init
$ $ gbp import-orig --verbose --sign-tags --pristine-tar
--upstream-branch=upstream --debian-branch=debian/master
~/Downloads/psrecord-1.4.tar.gz
$ git branch -a
* debian/master
pristine-tar
upstream
$ git logg
* commit 6dc6446feb741badb628632a20a8fd64be3dd98e (HEAD ->
debian/master, tag: upstream/1.4, upstream)
Author: Carsten Schoenert <***@t-online.de>
Date: Thu Aug 8 08:17:32 2024 +0200

New upstream version 1.4

* commit a309926d28d52527e88e3c96c7d2ec2c4b74347d (pristine-tar)
Author: Carsten Schoenert <***@t-online.de>
Date: Thu Aug 8 08:17:32 2024 +0200

pristine-tar data for psrecord_1.4.orig.tar.gz

Or you create the folder debian/ and here a file gbp.conf with this
minimal content:

[DEFAULT]
pristine-tar = True
compression = gz
debian-branch = debian/master
upstream-branch = upstream

and use than for importing this command

$ gbp import-orig --verbose --sign-tags ~/Downloads/psrecord-1.4.tar.gz


If you are not that familiar with the GitLab/Salsa UI I strongly suggest
you start the packaging in your own namespace and ask for reviewing, the
git tree can later be easily moved into the DPT namespace!
In your name space you can do e.g. force pushing, branch and tag
deleting that are not allowed normally if you use the official DPT
namespace.

For now I suggest to delete all content in
https://salsa.debian.org/python-team/packages/psrecord so an empty
repository is left.

Also add please some more information into the field of the project
description e.g. what the upstream url of the project is.

If you not able to delete the now existing stuff please raise your
hands. The repo could also moved into your namespace so you would have
full access rights.

BTW: Within the ITP #1075810 you stated you want to maintain this
package on your own, did you changed your minds?

And please use python-psrecord as source package name, psrecord is quite
generic. A name python-psrecord would show it is a Python related package.

[Martin]

Post by Carsten Schoenert
$ gbp import-orig --verbose --sign-tags --pristine-tar
--upstream-branch=upstream --debian-branch=debian/master
~/Downloads/psrecord-1.4.tar.gz

I suggest to use `upstream/latest` as upstream branch.
It spares you separating upstream/latest, upstream/master,
upstream/whatever later.

Cheers

[Carsten Schoenert]

Hi Martin,

Post by Martin

Post by Carsten Schoenert
$ gbp import-orig --verbose --sign-tags --pristine-tar
--upstream-branch=upstream --debian-branch=debian/master
~/Downloads/psrecord-1.4.tar.gz

I suggest to use `upstream/latest` as upstream branch.
It spares you separating upstream/latest, upstream/master,
upstream/whatever later.

again, using plain 'upstream' is current DPT policy. :-)
And it's a good choice to me.

For me using 'upstream-1.x' or 'upstream/1.x' doesn't make much
difference as branch name for keep track of e.g. the 1.x release.

But using 'upstream/latest' instead of just 'upstream' makes much of
difference in case you need to deal 80%-95% with releases that are the
current rolling release, it safes me much more often from a needed
further completion of the branch name!

In other words, I would be against changing the current policy regarding
the default upstream branch name.

[Carsten Schoenert]

Thanks everyone for chiming in !
Debates around the branch name aside, I still can't find out how to
access the Gitlab settings button to change the default to anything.
It's a permissions thing I think. When I access a project under my
personal namespace I see the settings button, all is well. Here, it's
just missing. I was able to create the project, of course.

The structure of the tree hasn't changed since the last time i was
looking into, did you read my previous email in detail?

$ git logg
* commit 4c0b559c9f60321be2fa412d73555ab38c517f16 (origin/pristine-tar)
Date: Wed Aug 7 19:11:03 2024 +0300
pristine-tar data for psrecord_1.4.orig.tar.gz
* commit 1443d1a19aeed367f2f2131757f01e2b9eafcfb4 (tag: upstream/1.4, origin/upstream, origin/debian/master, upstream)
| Date: Wed Aug 7 18:46:41 2024 +0300
|
| New upstream version 1.4
|
* commit 4c41bddf5c750a5c694aaba42c8252b444856ff7 (HEAD -> main, origin/main, origin/HEAD)
Date: Wed Aug 7 15:21:38 2024 +0000
Initial commit

The structure of the tree is simply wrong, given you are at the
beginning I suggest to drop the current tree and restart from scratch
within your namespace.
For me it makes no sense to work further on that base. It make things
unnecessary harder.

Once it's working on your side it's easy to push then the tree to the
repo on the DPT in Salsa again.

[Alexandru Mihail]

The structure of the tree is simply wrong, given you are at the beginning I suggest to drop the current tree and restart from scratch within your namespace.
For me it makes no sense to work further on that base. It make things unnecessary harder.
Once it's working on your side it's easy to push then the tree to the repo on the DPT in Salsa again.

I'll do that, thanks for the tips !

--
Regards
Carsten

Cheers,
Alex