Setting the release target on debian/changelog

[umläute]

On 2015-05-27 15:14, Felipe Sateler wrote:

> 
> 1. I understand our current wiki document to imply that I should set
> the target to unstable even if I am being sponsored. This has the
> benefit of allowing sponsors to use automated tools such as PET[2] to
> see which packages are ready for upload.
> 2. I understand your comment (and previous comments on the list) to
> imply that only the person actually uploading should set the target.
> This loses the above automation possibility but allows the sponsor to
> modify the changelog more easily with dch (as having a target would
> make dch create a new entry).

no, that's not what i wanted to say.

i think that the "maintainer" should set the release target, whether
they are being sponsored or not³.

but the package in question is in the middle of the review (it's the
second round now).
at this point i feel that it is simply too early (that's what i meant by
"*currently* to be determined by your sponsors"), esp. together with the
tendency to re-write git-history whenever "such" things happen. (which
was my impression, hence the long rant in my original mail).

> 
> I am fine with either, and I don't think we ever leveraged PET that
> much, so maybe we do not lose much by going with 2. Which one do we
> currently use? I have not sponsored that much lately, but what I did
> is follow number 2.


but i think there is a slight difference between team maintenance and
sponsoring. (thank jonas for my opinion:-))
what does "sponsoring" mean in a team? i think that teams are more than
just a convenient way to find likely sponsors.

so in general for our team i prefer "#2", where the main maintainer and
the nominal sponsor (that is: the DD with uploading priviliges) work
together on the package (that is: they both commit the git).
once they are both satisfied, the release target gets set und uploaded.


the package in question was slightly different, as it is currently
hosted on a different repository, where we (the team) don't have write
access to.
so i automatically fell into a "sponsor/sponsoree" behaviour, where "#1"
does make sense, once the package is in a "good enough shape".
it's just that i don't think that the package currently is.

fgmasdr
IOhannes

³ "maintainer" being a real person in this context, not a team