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. 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
