[Twisted-Python] twistechecker and twisted-dev-tools as part of twisted main repo

[Glyph]

> On Mar 18, 2015, at 1:38 AM, Adi Roiban <adi at roiban.ro> wrote:
> 
> On 18 March 2015 at 05:43, Glyph <glyph at twistedmatrix.com> wrote:
>> 
>>> On Mar 16, 2015, at 2:17 AM, Adi Roiban <adi at roiban.ro> wrote:
>> 
> [snip]
> 
>> I'm approximately -0 on this.  I don't like the idea of dumping a bunch of
>> code into the main Twisted repo that isn't distributed along with Twisted
>> (personally I cannot wait to get rid of the "admin" directory entirely), but
>> I also see your point about the tool being a part of the process.
> 
>>> Twistedchecker  has become an important part of dev process and I feel
>>> that the reviews for this project should be more visible.
> 
>> To be fair we are only just now getting down to a reasonable latency on
>> Twisted reviews, and it is still a fairly small audience reviewing.  This
>> may just lengthen the Twisted review queue :).
> 
> As commented earlier, any tickets which sits idle in the review queue
> for more than 1 week is not reasonable for me
> 
> Some changes in twistedchecker are there to help you with general
> review process so if we land them first future reviews might be faster
> as you no longer have to stop and check for false positives in
> twistedchecker builder.

Annoying issues with twistedchecker are certainly a problem, and I don't want to dissuade you from working on them, but to be honest, they have not been a significant source of blockers for me lately.  I have reviewed plenty of tickets this month <http://twistedmatrix.com/highscores/> and twistedchecker rarely came up.  Now, granted, this is probably partly because of your other recent work, so, it's certainly valuable.

> I don't agree with your priority... but judging by the fact that
> pyflakes patches took so long to land and nobody is pissed of by
> twistedchecker I feel in minority :(
> For me improving the infrastructure and the tools used by the
> developers is more important than the Twisted code itself.
> 
> It seems to me that you are suggesting that we can build a state of
> the art skyscraper with bamboo scaffolding and only use our bare hands
> and later we can look into creating power tools and advanced cranes
> and scaffolding.
> 
> Maybe we are used with the fact that you can only run static code
> analysis on buildbot and for that you need a commit and to manually
> trigger a build by filling a web form and wait 2 minutes for results,
> but this is stone age :(
> 
> pyflakes and twistedchecker should run in less than 1 second on local
> computer. To optimize speed the checker should be smart and only check
> the files which have changes since trunk.

Twisted should also seamlessly parallelize over multiple cores.  It should also have good operational visibility, tracing, and a clearly-documented deployment story.  It does not strike me that any of these are substantially more important than the others.  While the tools aren't great, what I have spent most of my time struggling with lately is how to document things clearly, not tool issues.

> ---------
> 
> What I am trying to do is to convince other Twisted developers that
> tools and infrastructure are important and they should be top
> priority.
> I am advocating for replacing primitive tools.
> 
> The current review process is a pain for new non-commiter
> contributors. Read-only clone of svn, manual patches attached to trac,
> review commend digested into a single comment, new branches created
> for conflicting changes... etc

In my mind, the biggest tools problem is getting us onto a DVCS (which means "git" since git has won the DVCS wars). That means being able to deploy a testing site to make sure we haven't broken stuff, which means a Vagrantfile for braid.  I put in quite a lot of effort improving the state of our build farm earlier in the year, and ops stuff is only so rewarding, so I'm still a little burnt out on that.

If we had a DVCS though, the current conflicts on the logging branch would be easy to resolve, and as it stands they're not.  Many of the other issues you're talking about are hypothetically a big issue but this one is practically affecting progress a lot, since all of the builds are failing and multiple branches now need to be manually rebased.

> Developing good tools take a lot of effort... so does writing good
> tests. Tools should be at least as important as the code or the tests
> . In fact, tests are just a tool to help you develop code.

No argument there.  But there's plenty of testing we don't have either - fuzz testing, for example.  Our performance tests are kind of a mess, and we don't have alerting on performance regressions.  No one of these issues strikes me as obviously the #1 out there, overriding everything else that's going on with the project.

>> So, I do have an alternate proposal - perhaps you should just announce
>> changes to twistedchecker on this list, and land changes to it without
>> review if nobody objects within a week or so.  If you're making changes that
>> are time-sensitive and there is an insufficient community to participate in
>> reviews, then I think it's fair to say that they shouldn't be reviewed.  If
>> anyone objects to the changes that are going in, they can always sign up to
>> do reviews :).  I have implicitly instituted such a process for
>> Twisted-umbrella projects like Imaginary and Vertex, where there are not
>> enough active contributors to sustain development.
>> 
> 
> Beside twistedchecker there are also twisted-dev-tools and the repos
> from twisted-infra organization.
> 
> I am not happy about cowboy / one man show coding. Merging a change
> without a review as this will break things for sure.

I'd definitely prefer more participation but I can't synthesize contributors out of thin air.

> My alternate proposal is to try to raise awareness that good tools are
> at least as important as good tests and have more people reviewing
> code for tools and work on improving the tools and to consider them an
> integral part of the development process.

I am personally unconvinced that this is what I should spend my time doing, just because I already have an already never-ending list of things to work on within Twisted, but I really, really hope you are able to convince many others.  It would certainly make my life a lot easier ;-).

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20150318/2a3c8d7b/attachment-0002.html>