Dear Nilesh, Am Fri, Dec 09, 2022 at 03:12:35PM +0530 schrieb Nilesh Patra: > > I'm considering reverting the version bump (shame on me I did not tested > > ntcard before uploading). > > I'm personally quite annoyed with this, I suppose your uploads, or rather > team uploads have broken quite a few packages in the past days. It was > first t-coffee update that broke biopython, and then mcl which broke pplacer > and now this.
I think this "common feature to break something" is quite different in the single cases. It was pretty hard to estimate the effect of the t-coffee case. A lot of effort was done to fix its autopkgtest in advance. I simply assumed that passing its test is sufficient for an upload. While the breaking upload of MCL was not intended I would even insist that there is a point in the breaking upload. MCL is a popular program which we should deliver in its recent version. The support and cooperation by upstream rectified this. The fact that some packages like pplacer depend from a patch by third party which is not maintained by its author since 10 years might mean that we will possibly loose these packages which is a shame but may be the fate of those packages. However, there is some hope that MCL upstream might find a solution. > The mcl update also most likely needs to be rolled back. The ocaml changes are > not compatible with the new version of mcl, and someone needs to update > pplacer > too to make sure that it is compatible with newer mcl. There is some hope for an updated OCaml patch[1], thought. If the OCaml patch can be updated that would be great. If not I see no chance to keep pplacer in the long term. > I want to make it a mandatory policy: do NOT upload packages randomly. Run > ratt > or run https://salsa.debian.org/ruby-team/meta atleast given that we are > close to > release, random updates of not so important packages is un-necessarily > breaking a > lot of things. I confirm that running ratt or meta of Ruby team would be a good idea in some cases. However, I disagree to make it mandatory in policy. Picking three cases of uploads from the number of all uploads is not a very strong argument. We have *lots* of uploads pending for the next couple of weeks to meet the freeze. Delaying these just because three broken uploads (one is fixed meanwhile and there is a clear way to fiy the second for ntcard by reverting the vesion bump of nthash if upstream does not respond timely) is not a good strategy in my eyes. I perfectly agree that running autopkgtest could be made mandatory in policy, thought. Kind regards Andreas. [1] https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-December/105589.html -- http://fam-tille.de
