>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments -------------------
Ian> ...
>> I realize that not everyone wants all developers to have push
>> access to their packages. If you have a firm idea about that,
>> then this recommendation is not for you. I also realize that by
>> starting by recommending the debian group I'm recommending a more
>> permissive maintainership model closer to low threshhold NMU than
>> only NMU my packages after explicit confirmation. I think that
>> the dh discussion supports the conclusion that we are OK with
>> that as a project *as a recommendation*. If a maintainer doesn't
>> like that level of openness, that's fine. My take though is that
>> when recommending what to do to people who do not have
>> preconceived ideas, more open policies like the debian group and
>> low threshhold NMUs are in alignment with the project.
Ian> I absolutely have no problem with recommending this as a
Ian> practice to the individual maintainer who doesn't know better.
Ian> However, for this practice to be useful:
Ian> 1. The maintainer's git repository branch format must be
Ian> documented. Otherwise another contributor has to guess. This
Ian> could be done either by doing maintainer uploads with dgit
Ian> (since recent versions of dgit include the maintainer branch
Ian> format information in the git tags), or perhaps by writing
Ian> something in README.source.
Makes sense.
My take is discussion on debian-devel strongly supports making it easier
to figure out what branch format people are using.
Ian> 2. We need to have a shared understanding of when people may
Ian> push to branches in the debian/ repository. I think you are
Ian> proposing that the answer be "if you do an NMU". I would
Ian> support this but it is a change to current practice. We also
Ian> need to understand how this relates to the recommendation to
Ian> NMU to DELAYED.
I'm not proposing a change to current practice.
I *think* that the documented practice may not be in alignment with
what happens.
That is, it seems like Debian developers are much more conservative in
how they use the debian group than is permitted by the wiki.
I use the debian group for my packages.
My experience has been that sometimes people push obvious things like
changelog cleanups without asking. Sometimes I get merge requests.
People will sometimes push fixes to areas of the code they have been
working on especially after I encourage them to do so.
Yes, I could have just given permission to push. I probably would not
have done so in the instances in question.
I understand this is one person's experience not actual data.
I think in this discussion we can recommend that interested parties
revisit the wiki documentation and see how it matches to reality after
running with the debian group for a few years.
I did do a bit of looking at data.
In my unstable sources.list, there are 17863 source packages that
include salsa.debian.org in the vcs-git. Of those, 2192 are in the
debian group.
That's the largestsingle group; perl-team (next) comes in at 1417.
The debian group is larger than all the individual accounts used on
salsa combined according to vcs-git in unstable.
So, what I'm seeing is that most people maintain packages in teams.
When they choose to maintain packages not in an explicit team, the
debian group is the dominant choice.
That choice is common enough that we have a strong presumption that it
actually works for people. If it were a complete mess of people pushing
without thinking or considering consequences we'd be hearing about it
more.
My take is that I think I have sufficient support for my original
recommendation on using debian at this point. Adding Ian's
recommendation that you need to document the branch format makes sense.
Revisiting what current practice is for the debian group and how that
interacts with NMUs and delayed also makes sense.
I don't think we need to block on that happening. I do not plan to lead
that discussion: I don't think I have time.
As always, continued feedback welcome; this is where I see things at
this point in the discussion.
--Sam
