[Aptitude-devel] Aptitude 0.6.10-1 (mentors.d.n)

Axel Beckert abe at debian.org
Tue Feb 11 15:30:53 UTC 2014


Manuel A. Fernandez Montecelo wrote:
> 2014-02-10 09:32 Daniel Hartwig:
> >On 10 February 2014 17:00, Daniel Hartwig <mandyke at gmail.com> wrote:
> >>On 10 February 2014 16:00, Daniel Hartwig <mandyke at gmail.com> wrote:
> >>>Your upload of the package 'aptitude' to mentors.debian.net was
> >>>successful. Others can now see it. The URL of your package is:
> >>>http://mentors.debian.net/package/aptitude
> >>>
> >>>The respective dsc file can be found at:
> >>>http://mentors.debian.net/debian/pool/main/a/aptitude/aptitude_0.6.10-1.dsc

I'll have a look at it.

I'm though a little bit surprised about the version number as there
was no discussion beforehand (besides mentioning it about two years
ago and one mentioning by me in a question about 0.6.10 vs 0.7) at all
about it. The changes in the proposed upload though definitely
validate this version number.

In my proposal I focussed on a git workflow because most of the heated
discussion was about commits and reverts in the past while e.g. the uploads were discussed and there was a consesus in the end.

To work as a team we _all_ must _avoid_ to upset others, also by not
doing bigger decisions without discussion before.

> >>Will upload again soon, just updating some libdevel files on this machine first.
> >
> >Done.

Like Manuel, I missunderstood these sentences first, too, but I now
think you talk of a reupload to mentors.debian.net, not to Debian

> There are several things wrong with what you have done:

While there seems no bad word in Manuel's mail, for me there swings
bad temper and aggressiveness in that mail -- which can make things
worse. I know it's hard and e-mail is a medium which doesn't transport
emotions well and hence leaves room for interpretation of emotions --
often in the wrong direction.

> - You didn't participate yet in the discussion about working together
>   effectively,

Daniel agreed to the workflow only in a private mail. I expected to see a
public mail from him, too, but IIRC none came.

>   still you found time to go ahead with this without even
>   announcing it

Yeah, I was very surprised about that move, too. I strongly suggest
that we start future releases with proposals.

But then again, the upload was only to mentors.d.n (twice as it seems)
and hence could be seen as a proposal. IMHO not the smoothest way to
do such a proposal, but acceptable.

>   If you're not going to abide to the proposed rules, the rest don't
>   have to do it, either.

Well, there wasn't yet a specific proposal about how to do releases
yet, was there?

> - We were discussing what to do with the releases, in particular
>   considering if it was a good idea coupling the packaging change of
>   enabling the russian documentation or not, which has effects on the
>   delay for the package to get to the users.

Yeah, but I don't think that's not a big issue as the discussion
IIRC showed advantages of both variants and we did more discuss about
putting the russian docs in or not than if the next release
will be or -- we didn't talk about the next
upstream release much yet IIRC.

So yeah, I'm fine with doing a new upstream release instead of as the changes validate the version change. (see
http://semver.org/ -- and I'm ignoring the leading zero.)

I though think the way this was "announced" was suboptimal.

Additionally I think that tags on Debian packages should only be made
_after_ or at least at the same time of the upload to Debian. (c.f.
At least that's the common workflow in e.g. the Debian Perl Team.

> - You didn't give the chance for Axel to reply (he replied later than
>   you created the release).

I don't want to suggest that Daniel would have uploaded to Debian if
DM-Upload-Allowed would be still in place, but I must admit that I've
read his mail first that way, too. (I hope I managed to remove all
things from this mail which were based on that misinterpretation.)

>   Initially the plans were that probably he was going to do this
>   release, and there was no indication to the contrary before you
>   pushed the release on your own.

I think I at least stated that I don't want to do an upload of any
important package while being sick. And that statement was not today
but IIRC yesterday. (And I'm still not yet fit again and sleeping a

For non-DDs, uploads to mentors.debian.net are a common way to propose

> - You didn't attribute the changes in the changelog to anybody but
>   you.

Oh, indeed. Not sure if I would have noticed.

>   No big deal for me, but if you complained about this recently
>   and are sensitive to these issues, you shouldn't do the same.

Independently of who complained about what -- when working together,
proper attribution in commits as well as changelogs should go without

I therefore propose to use the common changelog attribution style as
practised in I'm fine with both substyles:

* Sorting the entries chronologically (i.e. that names can occur
  multiple times) 

* Sorting the entries by author (and then either chronologically or by

Personally I tend to the latter.

Unfortunately there's no real common way to common way to properly
attribution changes done upstream. So I propose to do it similar to
how the lintian changelog mentions who did what (it's sorted by
changed files) -- by using the author's initials:

  * New upstream release.
    - [dth] New bla (Closes: #xyz)
    - [mafm] Fix fnord (Closes: #abc)
    - [mafm] New bar
    - [dth] Fix foo

  [ Daniel Hartwig ]
  * Some package foo

  [ Manuel A. Fernandez Montecelo ]
  * Some package bla

Would that be ok for all?

I'm not sure about the upstream changelog: There never was any
attribution in there so far for upstream developers. Do we want to
change that? If so, I think using initials there is probably the least
invasive form to change the format.

		Regards, Axel
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20140211/279a40dc/attachment.sig>

More information about the Aptitude-devel mailing list