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

Wed Feb 12 01:50:42 UTC 2014

2014-02-11 15:30 Axel Beckert:
>
>> >>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
>itself.
>
> [...]
>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.

I didn't misunderstood, I knew that it was to mentors.

But uploading to mentors and marking the package as seeking for a
sponsor (which might do the upload even if by mistake) can hardly be
called just a proposal, in my opinion.

As I already pointed out in the previous email, there's a thread about
that in this mailing list, which was completely ignored, and no
proposal has been made other than "I just created the new release".

Therefore I think that the 0.6.10-1 should be retired from mentors.d.o
and untagged in the VCS (as I said several times, I wanted at least to
include a few more changes discussed in BTS).

>> 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.

I don't think that it's aggressive, but requesting that if the other
people make an effort to agree to some rules to not upset others, then
others should be the first to follow the same rules that they
requested, and not disregard them.

>>   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?

This is a general rule after complaints in the recent past: to propose
changes and give people reasonably minimum time to review the
proposals, comment and propose changes.

I was proposing in the 6th of February whether to do a .4-2 release
with the packaging changes, already after previous discussions, hoping
to get Axel more involved in packaging (that's why I didn't do it
myself).

I also invited other people, mostly thinking about external
contributors (wishful thinking, I guess).  External or internal, if
one takes up the task, some proper notice must be sent.

>> - 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 0.6.8.4-1 or not than if the next release
>will be 0.6.8.4-2 or 0.6.8.5-1 -- we didn't talk about the next
>upstream release much yet IIRC.

After that email in the 6th, the new version was not created in the
proposed weekend, and since then several "upstream" fixes accumulated
in the meantime (and I explicitly mentioned in the bug reports that I
wanted to include at least another 2 or 3), I think that the same
reasoning applies as in the previous discussions: enabling the ru-doc
should probably not delay the "upstream" release (it can take days,
weeks or even months, we simply don't know).

So we should upload .5-1 and then .5-2 with the ru-doc (or .10-1 and
.10-2, or whatever).

I appreciate that not everybody can understand the same, but in any
case... debate, please.

>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.
>http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=tag;h=e2c2cc8f43a947fce23092dce56ed11717888462)
>At least that's the common workflow in e.g. the Debian Perl Team.

This too.

>>   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
>lot.)

The release was several hours *before* you said this, i.e., not
waiting for your reply.

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

Not in teams when there are people uploading, or at least I haven't
seen any example.

>I therefore propose to use the common changelog attribution style as
>practised in 0.6.8.4-1. 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
>  importance)
>
>Personally I tend to the latter.

I think that it's more common entry by author, yes (perhaps starting
chronologically by author).

New upsteam should always come first, I think.

>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.

Either way it's fine for me, I didn't use it in .3-1 and .4-1 because.

Whatever the decision, it should be applied consistently.

Cheers.
--
Manuel