Open Stack

On 01/04/2016 08:01 PM, Lana Brindley wrote:
> I’m late to this party because holidays (Thanks Anne for bringing it to
> my attention).
> 
> First of all, sorry this came as a surprise. I tried hard to make sure
> everyone who needed to know knew, but that’s naturally a difficult thing
> to do.
> 
> To the implementation details: I really am struggling to see how Reno
> could be used as a DocImpact replacement, unless you’re going to use it
> to somehow enforce that packages with DocImpact include some kind of
> text file in the commit. That would be complete overkill, and has the
> potential to really mess up the development repos (who needs random text
> files littered around?). Maybe I’m missing something here, though.
> 
> Really, the intent of the job is merely to check for a description after
> the DocImpact tag that gives the docs people a hint as to what you were
> thinking when you added the tag. It’s simply a time saving measure on
> our part, and sometimes a thing that saves a large amount of human time
> needs to take a small amount of compute time. I don’t think that’s a big
> ask, but again, please correct me if I’m wrong.
> 
> In short, I would rather remove the DocImpact facility entirely than try
> and turn a tool designed for a completely different task to this
> problem. However, as this is the first complaint I’ve seen about this
> solution since starting working on this thorny problem nearly a year
> ago, I can’t help but wonder if we’re overreacting? Do people genuinely
> hate this solution enough that we need to go back to the drawing board?

Yes. Because as I described it scuttles a whole other long term goal
(which is being able to update commit messages and keep Jenkins votes).
Voting based on commit messages is a thing we need to not be doing.

You can score based on content in tree, just not commit messages.

	-Sean

-- 
Sean Dague
http://dague.net