On Tue, 6 Mar 2018 15:01:23 +1030 Simon Lees <[email protected]> said: > > > On 06/03/18 12:51, Christophe Sadoine wrote: > > Then, it would be great if there was a tool to detect an api/theme > > break... and additions of api? > > I think a theme break tool is possible and should be done, not sure > > about the api. > > > There are API break tools available, currently they struggle with > differentiating between beta and release api automatically, currently > you will get a number of interface related breaks. > > > It would also be nice if at least one human reviewed what you want to > > merge. You shouldn't trust anyone even yourself. Humans always make > > mistakes. > > Humans can make mistakes, but the problem here is its a bunch of extra > work and delays, you may have to wait a few days for a human review, > that and some people already have a backlog of stuff to review from > people who haven't got commit rights yet. I don't think there is the > manpower for this atm.
tbh platforms is an issue. windows is kind of big as setting up a cross-build environment is a fair bit of work. setting up a windows vm costs money to test (need licenses, or if you can scrounge one off another pc you have/had). osx is worse in that you have to go buy hardware to run osx to test. i think making it a requirement that every commit work on every platform is not viable UNLESS: 1. a windows cross-compile env is available to developers (e.g. ssh into a vm set up for this with clear documentation and scripts/tools to do the builds. i have one set up for me at home). 2. a vm with remote display that developers can use to run/test changes easily. 3. an actual osx box that developers can ssh into and compile and runa nd test and remotely view/interact with like the windows vm. 4. same for freebsd etc. if a platform is on EASILY accessible and able to be EASILY worked with, then making this a requirement to pass a build/test on that platform is silly. developers have to be able to do incremental builds. not a "wait 10 mins for the next build cycle to happen then wait another 10 for the log to see if it worked this time". that's fine for reports. it's not fine for actual development. if this infra existed and worked well, THEN i think it might be sane to start adding "it has to pass a build test". then deciding on what platforms have to be supported is another step. this has to be pain-free or as close as possible to that. not to mention... the test suites need to actually be reliable. i just found one of the ecore_file tests was grabbing a page from sf.net ... and now sf.net is refusing to servie it anymore thus test suites keep failing. tests that are fragile like this should not be some gatekeeper as to if code goes in or not. if a test suite is to be a gatekeeper it has to be done right. that means it has to work reliably on the build host. run very quickly. things like testing network fetches has to not rely on anything outside of that vm/box/chroot etc. etc. ... and we don't have that situation. this probably needs to be fixed first and foremost. not to mention just dealing with check and our tests to find what went wrong is a nightmare. finding the test that goes wrong in a sea of output ... is bad. so my take iis this: first work on the steps needed to get the final outcome. better test infra. easier to write tests. easier to run and find just the test that failed and run it by itself easily etc. it should be as simple as: make check ... FAIL: src/tests/some_test_binary and to test it i just copy & paste that binary/line and nothing more and i get exactly that one test that failed. i don't have to set env vars, read src code to find the test name and so on. ... it currently is not this simple by far. ;( > > Communication: > > Discussion can happen on irc/mailing list, but decisions should not. > > There should be only one place where decisions are made. And it should > > be phab. > > The mailing list is good for questions/discussions but it is very easy > > to forget a mail. A ticket has a status and it stays there until you > > resolve it. > > Decisions should have a clear status and should not be dangling like a > > mail thread could be. > > And you would also have proof there was a discussion and how a > > decision was made. > > Someone joining the project would have a hard time searching though > > the mailing list/irc logs to find information about a specific issue. > > So I think all important decisions should be in one easy > > searchable/referable place. (it doesn't have to be phab but it is what > > we have now) > > As I said on IRC I don't think phab will work efficiently it will be > more effort getting the right group of people subscribed to the ticket > then the amount of benefit we gain, there will always be someone who > didn't get subscribed for some reason, and maybe the scope will broaden > slightly and people who didn't think they would care might end up caring > and miss the discussion. i think there has to be a dividing line between big and little things. it's fuzzy - sure. not every little thing needs some kind of consensus system. major changes in direction do. they need to clearly go over that direction, design or whatever change. the existence of such wiki pages, tickets, whatever should be clearly advertised here on this mailing list. also any summaries of final decisions should be here too as well as in commit logs (see below) > Really all we need is the original Author to summarize the discussion in > one email and add it to a wiki / roadmap thingo. If the main person > working on the feature isn't willing to do that then maybe a project > manager can. it should be summarize in the COMMIT. either there in full text or as a link to something that will survive for a long time. considering how many commits now refer to a ticket on phab or a patch review, i think we can just as well deal with it and accept that phab is here to stay, good and bad points, so a link to something on phab would be acceptable. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
