+1 with John. Renaming autotest_lib to autotest will have a hugely impact to ChromeOS test automation project, since we need to go over through all test cases to change the import statement...
Eric On Tue, Jan 4, 2011 at 9:21 AM, John Admanski <[email protected]> wrote: > > > On Tue, Jan 4, 2011 at 9:08 AM, Lucas Meneghel Rodrigues > <[email protected]>wrote: > >> On Tue, 2011-01-04 at 14:31 -0200, Eduardo Habkost wrote: >> > On Tue, Jan 04, 2011 at 02:15:26PM -0200, Lucas Meneghel Rodrigues >> wrote: >> > > I see an opportunity for us to do some cleanup on that and eliminate >> > > bin. Now, we need a plan of migration, a carefully made patchset, and >> > > tons of testing. Perhaps the entire contents of bin can be dropped >> into >> > > client altogether, but that is not too symmetrical with common_lib. >> > >> > IMO there's no need to hurry. If we think it is worth it, we can slowly >> > move libraries out of bin and keep only executable scripts, but no need >> > to do it in a large step. >> > >> > About symmetry with common_lib: I think common_lib is the aberration (it >> > could live outside 'client', but we have the issue of sending only the >> > 'client' directory to test hosts), so I wouldn't worry about making the >> > client-only modules layout match the common_lib layout. >> > >> >> It seems to me that we can make things much better by doing some simple, >> mechanical steps: >> >> 1) Change autotest_lib to autotest >> > > I think that from an aesthetic point of view autotest is a nicer name than > autotest_lib, but it does clash with server/autotest.py so if you want to > rename the top-level package you'll need to rename that too, which is more > painful than it sounds because server/autotest.py is a very prominent part > of the server-side test API. It also amplifies the pain of step 4 a lot > since it means updating just about every internal server-side control file, > anywhere. > > >> 2) Move common_lib to common >> 3) Move stuff from client/bin to client altogether >> 4) Telling everybody that has internal tests/site extensions to adapt >> their tests to the changed API. >> >> The 3 first steps will generate *freaking huge* patchsets, but it's just >> mechanical work. As long as it's well tested and audited (pylint comes >> to the rescue here), it's not that dangerous. >> >> Now, 4) is probably the hardest part, as we have parties with large site >> repositories, google being the biggest. So for me, is all a matter for >> the google folks (Chrome OS and other internal users) to pronounce about >> it. I won't even try to make a change if those guys do not feel OK about >> it. >> >> Any comments guys? >> >> Lucas >> >> > -- Eric Li 李咏竹 Google Kirkland
_______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
