Hi, Manuel A. Fernandez Montecelo wrote: > 2014-02-10 09:32 Daniel Hartwig: > >On 10 February 2014 17:00, Daniel Hartwig <[email protected]> wrote: > >>On 10 February 2014 16:00, Daniel Hartwig <[email protected]> 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 0.6.8.4 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 itself. > 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 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. So yeah, I'm fine with doing a new upstream release instead of 0.6.8.4-2 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. 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. > - 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 lot.) For non-DDs, uploads to mentors.debian.net are a common way to propose uploads. > - 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 saying. 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. 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 <[email protected]>, 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
signature.asc
Description: Digital signature
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
