On 12/15/2011 1:56 AM, Alon Bar-Lev wrote: > On Thu, Dec 15, 2011 at 9:43 AM, Martin Paljak<mar...@martinpaljak.net> > wrote: >> On 15/12/11 01:43, Alon Bar-Lev wrote: >>> Oh... I was so excited I missed some important issue. >>> When submitting a patchset it should be tested for build as atomic unit. >>> Currently the system tries to compile each changeset by it-self. >>> Many times this will not work, as patchset is divided into logical >>> sections suited for review not for build. >> >> I'd prefer the opposite, given your exact sample: >> It would be best if not a single commit would break the build, on any >> platform. >> >> It is probably a bit harder for some structural changes, but most >> probably possible. >> >> As said, I'm working on figuring out how to make the Gerrit changes >> autobuilds happen on all platforms (Windows included) as at the moment >> it is a simple Linux tarball build (the Gerrit configuration seems to be >> tied to master) >> >> Splitting patches would make sense if it really was a huge change per >> se, but it is not. >> >> Use git rebase --interactive to merge all these into a single commit >> with a descriptive commit message before publishing (melding in all >> those single line messages would also help) >> >> The goal is to separate development (small things patched together until >> it works) from releasing (meaningful changes with enough documentation) >> >> Fixing Windows build after a change that "broke" it is meaningful to me >> as a developer but useless for "normal people". Removing libltdl >> dependency is understandable to a wider audience. >> >> Martin > > Here we completely disagree. > The whole point of sending changes to review is to allow humans to go > over code without actually building or testing and get valid feedback. > Doing so on large changesets is something that is almost impossible.
Well, maybe. But it also allows one to fetch, build *and* test. For example, by testing Viktor's SM patch, I found problems using cards that did not use SM. > It is much easer to guide reviewer at the process of changes by > splitting the change into logical pieces. > Think of it as the story of the change presented by the developers to > the audience without verbal synchronous meeting. > It is not that each line of code should be split, but the main building > blocks. > > Alon. > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
