Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments
>> -------------------
> ...
>> 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.
>
> I absolutely have no problem with recommending this as a practice to
> the individual maintainer who doesn't know better. However, for this
> practice to be useful:
>
> 1. The maintainer's git repository branch format must be documented.
> Otherwise another contributor has to guess. This could be done either
> by doing maintainer uploads with dgit (since recent versions of dgit
> include the maintainer branch format information in the git tags), or
> perhaps by writing something in README.source.
>
> 2. We need to have a shared understanding of when people may push to
> branches in the debian/ repository. I think you are proposing that
> the answer be "if you do an NMU". I would support this but it is a
> change to current practice. We also need to understand how this
> relates to the recommendation to NMU to DELAYED.
>
> 3. The answers to (1) and (2) need to be documented.
>
> I would like to suggest another possible widening of when to push to a
> branch in the debian group on salsa: "if you would do an NMU, but for
> some reason an actual upload is not desirable right now". Examples
> could include packages owned by QA, if a maintainer invites you to
> make a change, if a bug needs fixing but for transition or migration
> or similar release management reasons it is not a good time for an
> upload.
>
This first part is consistent with my intuition / understanding. I
haven't had time to absorb the rest.
d
