ubuntu-phone team mailing list archive

[Oliver Grawert <ogra@xxxxxxxxxx>]

hi,
Am Donnerstag, den 05.06.2014, 15:57 +0300 schrieb Alberto Mardegan:
> On 06/05/2014 03:05 PM, Oliver Grawert wrote:
> > With the current quality of changelog entries people provide to us
> > this is not possible at all. We have to dig into each and every
> > changeset and actually need to understand what code changes in
> > there do, changelog entries end up being something like "* rename
> > foo to bar" or "* new feature blah" across ten packages with no
> > detailed explanation at all what code was changed, if there were 
> > added or removed dependencies or any additional code reworks.
> 
> Unless I'm misunderstanding you, I disagree. I think that
> debian/changelog shouldn't try to go too much in detail of the changes
> and only highlight the packaging changes and the newly added features.
> 
> I think that the information you are looking for should be found in
> the upstream changelog (aka bzr history, nowadays).
> 

Well, if you like to not be able to land your code we can indeed do
that, during the last four days we could only land two features (and all
silos are fully filled atm) because both of them cause breakage and we
spent several hours trying to find out about the respective change that
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 ... 

If you find someone else outside of the landing team approving your
packaging changes, feel free to get their +1
As i said above *I* wont approve such changelogs anymore for the benefit
of all of us being able to land stuff at an acceptable velocity ... we
can not afford to be in TRAINCON-0 for more than a week, it harms
everyone and i think adding a two liner about *what* changed in the new
upstream version isn't asked to much 

ciao
	oli

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