On Wed, 2016-02-03 at 16:04 +0000, Jonathan Wakely wrote: > > If I send these two provenpackagers a somewhat hostile email, are you > > going to blame me? I have no problem with most provenpackager > > changes. In general, they have an obvious purpose and save me the > > work of making the same change myself. But changes like the ones > > above make more work for me, work that could have been avoided if the > > provenpackager in question had just bothered to make some attempt, any > > attempt, to contact me first. > > I don't think that's always realistic to expect. > > When a provenpackager is rebuilding *hundreds* of packages at once, > and trying to deal with maybe dozens of build failures, sending emails > to all the package owners and waiting to see if they respond promptly > is not an efficient way to get things fixed. Waiting for a reply adds > a lot of latency, and then you have to context-switch back to a > package you were dealing with a day or two ago. That's impractical > when you have a patch ready to go now and loads more packages to look > at. > > Sometimes a provenpackager will make a bad change, and that's > unfortunate, but it happens. Sometimes package owners make bad changes > too! :-) > > If I make a bad change to a package please do let me know. If I appear > to change things and walk away it's probably because I've moved on to > look at other packages that also need attention, not just a careless > hit & run. I would expect it's similar for others. Sorry but this sounds more like a process definition problem than anything. In fact, problems like this sound like they would be better dealt with by alerting the package maintainer and passing the ball to them. If the problem isn't dealt with quickly enough then perhaps that package should not be re -built at this time. There should be some responsibilities for package maintainers. And, surely, in this case the provenpackager has too much to do to pay suitable attention to changes needed and really does need to move on. Yes, there would be some need to define process around this so the ball could come back to a provenpackager on a second pass, hopefully when they have a little more time to attend to the problem, if there was no response from the maintainer. This reminds me of the saying "more haste less speed"! Ian -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
