On Sun, Nov 29, 2015 at 12:20 AM Stuart Langridge <
<email address hidden>> wrote:
> Michael: I see that my merge proposal was rejected for being old.
Yep - as were about 6 branches of mine that I'd not followed through to
landing (not for rnr, but other projects I was working in the same sweep).
> (Fine,
> it was also missing a couple of tests, but it wasn't looked at until ten
> months after it was proposed, and then was rejected for being old.) You
> see my concern about "every time my third-party app wants to query the
> data in a different way there'll be a long cycle time before Canonical
> provides it, and constant ongoing work for Canonical engineers"? When
> you say "it'd be slightly more difficult to get things you need
> landed"... if "slightly more difficult" means "wait nearly a year for a
> review" then I'd call that a little more than slightly.
Sorry Stuart - my fault - I should have been more explicit on my previous
reply that needed to follow-up with Fabien (who'd been working on and
maintaining the code-base) about the change. Unfortunately LP doesn't have
@username notifications, and I didn't check back.
> This is why I
> suggest that a much better way here would be to expose the back end and
> allow people to get at the data, at which point we can do what we want
> with it,
Yes, I'll do a manual notification to @Fabien (as he'll know whether the
rnr db has any sensitive info that would need to be excluded, such as
moderated reviews or whatever) and @beuno. Sorry I didn't do that the first
time.
> rather than lobbying for an API change which will take a very
> long time to happen.
>
I know it's no consolation to you, but it's the same for internal branches
- as above, my branches get rejected for the same reason if I don't follow
up and find someone to review/land. The difference is that it's much harder
for someone outside Canonical to get hold of people to follow up on a
branch and get it landed.
We really should switch to use *and maintain* a review queue of proposed
branches (which may be why Natalia was cleaning up old branches) so that
all branches are considered equally without needing to ping.
Hey there Stuart,
On Sun, Nov 29, 2015 at 12:20 AM Stuart Langridge <
<email address hidden>> wrote:
> Michael: I see that my merge proposal was rejected for being old.
Yep - as were about 6 branches of mine that I'd not followed through to
landing (not for rnr, but other projects I was working in the same sweep).
> (Fine,
> it was also missing a couple of tests, but it wasn't looked at until ten
> months after it was proposed, and then was rejected for being old.) You
> see my concern about "every time my third-party app wants to query the
> data in a different way there'll be a long cycle time before Canonical
> provides it, and constant ongoing work for Canonical engineers"? When
> you say "it'd be slightly more difficult to get things you need
> landed"... if "slightly more difficult" means "wait nearly a year for a
> review" then I'd call that a little more than slightly.
Sorry Stuart - my fault - I should have been more explicit on my previous
reply that needed to follow-up with Fabien (who'd been working on and
maintaining the code-base) about the change. Unfortunately LP doesn't have
@username notifications, and I didn't check back.
> This is why I
> suggest that a much better way here would be to expose the back end and
> allow people to get at the data, at which point we can do what we want
> with it,
Yes, I'll do a manual notification to @Fabien (as he'll know whether the
rnr db has any sensitive info that would need to be excluded, such as
moderated reviews or whatever) and @beuno. Sorry I didn't do that the first
time.
> rather than lobbying for an API change which will take a very
> long time to happen.
>
I know it's no consolation to you, but it's the same for internal branches
- as above, my branches get rejected for the same reason if I don't follow
up and find someone to review/land. The difference is that it's much harder
for someone outside Canonical to get hold of people to follow up on a
branch and get it landed.
We really should switch to use *and maintain* a review queue of proposed
branches (which may be why Natalia was cleaning up old branches) so that
all branches are considered equally without needing to ping.