Bug#682279: unblock: libweb-id-perl/1.921-3
Hi Jonas On Sat, Jul 28, 2012 at 06:10:15PM +0200, Jonas Smedegaard wrote: Hi Julien, and others, On 12-07-28 at 01:33pm, Julien Cristau wrote: For a request like this, if it takes more than 5 minutes to process it's a waste of our time. Having a clear changelog helps avoid that, as does not arguing or getting on your high horse when asked clarification questions. And by helping that, it helps get your request approved, which I guess is what you want? Yes, that is what I want. My apologies for not following rules and getting on my high horse. How to proceeed from here? Should I now... * Wait for you to ask clarification questions or make a verdict? * Make a new package fixing the bad things pointed out by Cyril - i.e. a) mention in changelog relevant bugs that was filed after last package release, and b) more descriptive changelog regarding how changes was made, and c) random noise reverted? * Something else? (I'm only spaeking as person involved in the bugreports mentioned) Only to clarify a), it is right the bug against libweb-id-perl was cloned afterwards from the librdf-crypt-perl bugreport. I think for the release-team it would have been enough to reference to that original bugreport on librdf-crypt-perl to have the background information needed, or to [1]. [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680805#17 I cloned the bug afterwards, to have the issue tracked. As *both* packages needs to be fixed in wheezy to have the FTBFS resolved for librdf-crypt-perl in wheezy (both #682277 and #680805) Regards, Salvatore signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
On Sat, Jul 21, 2012 at 20:55:27 +0200, Jonas Smedegaard wrote: Is the noise of the non-crucial changes so problematic (a.k.a. unpleasing) that the release team considers the current package unsuitable for getting an exception from the freeze? I honestly did not consider that noise as significant changes not related to the bug to be fixed, as it is phrased at the fine http://release.debian.org/wheezy/freeze_policy.html. Do the release team consider the package unsuitable for freeze exception due to the lack of bug reference in the changelog (the bug was unfortunately unavailable to reference at the time the package was produced and I honestly was unaware that such reference was problematic for the release team to get passed in the freeze exception bugreport)? Do the release team consider the package unsuitable for freeze exception due to the user-only oriented changelog entry - i.e. lack of verbose enough details in changelog for release managers to follow _how_ the issue was fixed? Would it be more helpful of me to upload another package release that rephrased the changelog to be more helpful for release managers to understand how non-newest-debhelper-style packaging was performed internally? Should I do that in addition to the user-oriented changelog entry or instead of it? Would it be more helpful if I had not asked these questions but instead just uploaded a new package fixing these three issues raised by Cyril? So I think I'll answer these all at once because I think they boil down to the same thing. For a request like this, if it takes more than 5 minutes to process it's a waste of our time. Having a clear changelog helps avoid that, as does not arguing or getting on your high horse when asked clarification questions. And by helping that, it helps get your request approved, which I guess is what you want? Cheers, Julien signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
Hi Julien, and others, On 12-07-28 at 01:33pm, Julien Cristau wrote: For a request like this, if it takes more than 5 minutes to process it's a waste of our time. Having a clear changelog helps avoid that, as does not arguing or getting on your high horse when asked clarification questions. And by helping that, it helps get your request approved, which I guess is what you want? Yes, that is what I want. My apologies for not following rules and getting on my high horse. How to proceeed from here? Should I now... * Wait for you to ask clarification questions or make a verdict? * Make a new package fixing the bad things pointed out by Cyril - i.e. a) mention in changelog relevant bugs that was filed after last package release, and b) more descriptive changelog regarding how changes was made, and c) random noise reverted? * Something else? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
On 12-07-21 at 01:05am, Cyril Brulebois wrote: Hello, Salvatore Bonaccorso car...@debian.org (21/07/2012): libweb-id-perl has a missing dependency which causes another package to FTBFS. I have cloned the original Bugreport now as [1], see in particular Jonas' message in [2]. [1]: http://bugs.debian.org/682277 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682277#17 no bug reference in the changelog isn't helpful… ...which is the reason it was provided in above email, I guess. I do believe inclusion of bug references in changelog is optional (see Debian Policy §4.4). +libweb-id-perl (1.921-3) unstable; urgency=low + + * Fix depend on libmousex-types-perl or libmoosex-types-perl (in +addition to recommending libmousex-types-perl). Surely this could have been more descriptive, like “fix misconcatenation for the CDBS_DEPENDS_ALL variable”. A naïve mind would be looking at debian/control otherwise, and would think something was overlooked… I agree that my choice of words was not ideal for release team review. My target audience when writing changelogs is our users, however, and I do find my actual changelog entry more descriptive for them than your proposed one. + * Relax to build unversioned on cdbs: Needed version satisfied in +stable, and oldstable no longer supported. + * Fix use pseudo-fields in copyright file (license-in-comment for +verbatim dual-license text covered in separate License sections, +and comment-in-license for non-verbatim parts of License sections): +File format 1.0 mandates License field to either be single-line or +include all licensing info. Looks like random noise to me. Just when I thought the rules were clear… http://release.debian.org/wheezy/freeze_policy.html Then reject it, if you find it too unpleasing!!! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
On Sat, Jul 21, 2012 at 11:02:33AM +0200, Jonas Smedegaard wrote: Then reject it, if you find it too unpleasing!!! I hope you realize that Cyril is only doing his job. You're not being helpful and albeit I'm tempted to just say No problem to that statement it would still leave an RC bug open. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
On 12-07-21 at 01:53pm, Philipp Kern wrote: On Sat, Jul 21, 2012 at 11:02:33AM +0200, Jonas Smedegaard wrote: Then reject it, if you find it too unpleasing!!! I hope you realize that Cyril is only doing his job. You're not being helpful and albeit I'm tempted to just say No problem to that statement it would still leave an RC bug open. Sorry for my brevity and for the trailing exclamation marks. I read the mail from Cyril and was puzzled as to how to react on it. Let me try in a nicer manner to elaborate on my confusion...: Is the noise of the non-crucial changes so problematic (a.k.a. unpleasing) that the release team considers the current package unsuitable for getting an exception from the freeze? I honestly did not consider that noise as significant changes not related to the bug to be fixed, as it is phrased at the fine http://release.debian.org/wheezy/freeze_policy.html. Do the release team consider the package unsuitable for freeze exception due to the lack of bug reference in the changelog (the bug was unfortunately unavailable to reference at the time the package was produced and I honestly was unaware that such reference was problematic for the release team to get passed in the freeze exception bugreport)? Do the release team consider the package unsuitable for freeze exception due to the user-only oriented changelog entry - i.e. lack of verbose enough details in changelog for release managers to follow _how_ the issue was fixed? Would it be more helpful of me to upload another package release that rephrased the changelog to be more helpful for release managers to understand how non-newest-debhelper-style packaging was performed internally? Should I do that in addition to the user-oriented changelog entry or instead of it? Would it be more helpful if I had not asked these questions but instead just uploaded a new package fixing these three issues raised by Cyril? Especially that last question I ask explicitly so that I can most smoothly help you guys do your jobs for other of packages I may be involved in requesting freeze exceptions for. Kind regards, and thanks for your great work, Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#682279: unblock: libweb-id-perl/1.921-3
Hello, Salvatore Bonaccorso car...@debian.org (21/07/2012): libweb-id-perl has a missing dependency which causes another package to FTBFS. I have cloned the original Bugreport now as [1], see in particular Jonas' message in [2]. [1]: http://bugs.debian.org/682277 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682277#17 no bug reference in the changelog isn't helpful… +libweb-id-perl (1.921-3) unstable; urgency=low + + * Fix depend on libmousex-types-perl or libmoosex-types-perl (in +addition to recommending libmousex-types-perl). Surely this could have been more descriptive, like “fix misconcatenation for the CDBS_DEPENDS_ALL variable”. A naïve mind would be looking at debian/control otherwise, and would think something was overlooked… + * Relax to build unversioned on cdbs: Needed version satisfied in +stable, and oldstable no longer supported. + * Fix use pseudo-fields in copyright file (license-in-comment for +verbatim dual-license text covered in separate License sections, +and comment-in-license for non-verbatim parts of License sections): +File format 1.0 mandates License field to either be single-line or +include all licensing info. Looks like random noise to me. Just when I thought the rules were clear… http://release.debian.org/wheezy/freeze_policy.html Mraw, KiBi. signature.asc Description: Digital signature
