ubuntu-phone team mailing list archive

[Oliver Grawert <ogra@xxxxxxxxxx>]

hi,
Am Freitag, den 06.06.2014, 10:34 +0300 schrieb Alberto Mardegan:
> On 06/05/2014 07:26 PM, Oliver Grawert wrote:
> > was at fault. If a package upload contains 6-10 bzr branches with 
> > changes made by different people in different places of the
> > package there is no way to identify the offending change anymore if
> > you only have a " * new upstream version" in your changelog ...
> 
> My question is "why do you need to rely on the changelog only?". It
> seems fairly obvious to me that when trying to identify a wrong change
> one would look at the bzr history and not at debian/changelog.
> It's so obvious, that I'm sure I'm missing something. :-)
> 
> Secondly: why would it be your duty to identify the wrong change?
> Shouldn't you just reject the upload and let upstream clean up the mess?

Your package upload ends up on the -changes mailing list, usually one
silo even lands in one chunk so they end up in one block there ... there
are features, even big ones where people write proper changelogs (most
of the ubuntu core-devs do for example), skimming over them, identifying
the faulty package and *then* looking into the details in the package
and eventually into the single MP branches can be done in minutes ...
whereas ... if you have a handful of packages with only generic
changelogs you are forced to go through all MP commits to find the
issue, which ... as the last week (and the still active TRAINCON-0
status) has pretty well proven, can take multiple hours ...

If you search something in a book, don't you use table of contents  or
the glossary ? or do you randomly open pages until you find the page you
were looking for by luck ? 

This is simply about being supportive to your co-workers in the
developer community, they don't know your code but will have to find the
issues with it  ... 

we could have been out of the TRAINCON-0 state days ago if the offending
pieces of code would have been easier to find. being in TRAINCON-0 means
that many features can simply not land, that several QA people need to
do extra work to explicitly test the few features we can let in. It
causes extra work for everyone and is easily avoidable by being a bit
more descriptinve in your changelogs.

ciao
	oli

Attachment: signature.asc
Description: This is a digitally signed message part