On Mon, Oct 10, 2011 at 02:22:05PM +0200, Alexander Sack wrote: > On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier <loic.min...@linaro.org> wrote: > > > On Mon, Oct 10, 2011, Deepti Kalakeri wrote: > > > 1) The board on which the hwpack can be booted > > > 2) The hwpack creation timestamp includes the date in yyyymmdd format > > along > > > with the time in hhmm format. > > > > > > The hwpack name does not include any defconfig related information, which > > > was used to build the kernel. > > > Do we need to use the defconfig name as well to be part of the hwpack > > name ? > > > Is there any other information you would like to include in the hwpack > > name > > > ? > > > Or do we need to continue with the current hwpack names ? > > > > We rarely use a defconfig alone; however in the case of kernel .debs, > > you should find the corresponding config under boot/config-`uname -r` > > in the .deb (dpkg-deb -x the kernel .deb to find the config). > > > > > (note that in the case of kernel CI we currently use pure defconfig > configurations) > > What I asked deepti to work on is to make the CI hwpacks exported > through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able > to the actual CI job they are coming from. > > Instead of exploding the hwpack name with more info, we could also > introduce a new directory level in the kernel_hwpack directory like: > > kernel_hwpack/ci_job_name/HWPACK1,2,3 > > ... and then leave the hwpack names as they are now. Maybe > improve the version to rather use the git describe version of > the kernel tree and not the kind of meaningless timestamp.
Looks better, but... We need unique build IDs, and these are the critical thing we need to reference from the build. Anything else seems likely to result in fragility later. The CI infrastructure can tell us what config and sources a given build was generated from, so not only do we not need to put this information in the builds, I believe that we _should not_. Sooner or later it will get inconsistent or wrong, whereas the CI server is authoritative. Also if we try to put metadata into filenames, it will keep being found to be wrong or insufficient, so we may have to heep changing it. By putting the build ID into the kernel image .deb or the kernel release string, we can find out everything we need to know about the build, regardless of whether we start with an installed target platform, the .debs, the hwpack or the hwpack URL. For convenience only, we can put the job name and build ID into the URL and/or the hwpack filename, and possibly in the hwpack metadata, but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism. Thoughts? Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
