ubuntu-phone team mailing list archive

[Oliver Grawert <ogra@xxxxxxxxxx>]

hi,
Am Freitag, den 06.06.2014, 09:42 -0700 schrieb Robert Park:
> On Fri, Jun 6, 2014 at 1:31 AM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
> > 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  ...
> 
> 
> Thanks for your message ogra, it's a perspective I'm unfamiliar with.
> I'm not on the -changes mailing list and working deep within the dark
> recesses of citrain gives me good access to the MPs, so usually I'm
> getting slapped in the face with the relevant MPs and bzr logs, which
> means debian/changelog is largely just irrelevant to me.
> 
> 
> One concern that I have about rejecting uploads solely because of a
> problem with the changelog content is that it leads to a situation
> like this:
> 
> 1. upstream developer spends a great deal of time writing new feature / bug fix
> 2. upstream developer documents the change in great detail in their
> bzr commit messages
> 3. upstream developer summarizes the change in reasonable detail in
> the MP message.
> 4. I assign a silo to them for building/testing
> 5. upstream developer initiates silo build and waits sometimes a long
> time for that to complete.
> 6. upstream developer spends a great deal of time testing their code,
> making sure it works
> 7. upstream developer gives me the green light to publish
> 8. a core dev says "this changelog is insufficient, start over!"
> 
> Now steps 5, 6, and 7 must be repeated just for a trivial changelog
> fix which consumes quite a lot of time for the upstream developer.
> 
> So, it makes me wonder, can there be some provision for editing the
> changelog without requiring retesting? Maybe the upstream developer
> who has to write a new changelog entry can just email it to the core
> dev who rejected the upload based on the changelog, and that core dev
> could upload a -0ubuntu2 with just the changelog fix?

Well, I think that can be a policy exception we can quickly add to the
landing process .
If an MP only contains debian/changelog changes it should simply not
require re-testing , that way you could just stick another MP on top
that fixes the changelog entry without much hassle. 

But after all I simply think that's some thing of common sense to add an
understandable description for your co-workers or other community
members to your change so they can understand what the change is about
and I think it is not to much to ask to write a two liner instead of
"new upstream" or "new feature foo" into a changelog/commit message.

Though I'm truely hoping asac's request for ideas above probably gets
the changelog handling higher up in the process stack as a part of the
MP approval process which means the core-dev ack at the end should not
need to return the whole process to the start ... 

I understand that there are two worlds, the macrocosm of someone
maintaining packages and the microcosm of an upstream dev who probably
writes detailed commits in his tree but info about these end never in a
debian/changelog ...
Today we already share many packages on the phone with the general
distro and distro people will want to be able to know what's going on
with the packages ... the more we work towards convergence the closer
these worlds will have to cooperate and info needs to get over the
fence, lets design our processes in a way that this is possible ;)

ciao
	oli

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