Hi Erich; Am Samstag, 26. September 2015, 17:05:56 schrieb Erich Titl: > Hi KP > > Am 26.09.2015 um 16:30 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Donnerstag, 24. September 2015, 13:08:14 schrieb Erich Titl: > >> Hi KP > >> > >> Am 22.09.2015 um 18:27 schrieb kp kirchdoerfer: > >>> In 5.2 a major target will be to finally get Erich's update mimic up > >>> and > >>> running > >> > >> A few questions > >> > >> - What is the 5_2 directory in the packages repository? 5.2.0? > > > > No. These are older packages provided for you during testing of upgrade. > > I need to rebuild the packages so it will take time to update the files in > > 5_2 > Why do you need to rebuild the packages? They should all be in the files > directory.
To be shure the Packages, kernel etc are inline with the release. I didn't commit before I started to make updates. As I tried to point before, requirements for upgrade doesn't fit well ino the build process. Most of the stuff could be done from the packages directories, but few files need to be collected from the builded images. This should be improved in the future - at least, once the upgrade process is fixed. > I believe we need one single central repository for the > released packages and IMHO the package repository would be a fine place > to keep them. Agree. > > ... > > > > I hoped you have an idea, depending on your knowledge of the upgrade > > script > > and your tests... > > Well, my idea was (and will remain) to fork off whatever into a 5.2.0 > branch and delete everything there which does not belong to 5.2.0, then > for 5.2.1 fork off 5.2.0 to just replace the specific files for 5.2.1 > and so on. Ok; definitely worth a try. > > I doubt you can work with git tags. > > So do I, they do not appear on the web interface, but branching off is > just as well for the packages. > > So I have a very good target for the upgrade script, 5.2-beta1. As soon > we can build a definite 5_2 in the packages repository I will branch > 5.2.0 off for upgrade. I believe we will see the that branching here is > a good way to keep the repository clean, as long as we keep up the > discipline to just replace the affected files in the packages repository > for a new release branch. This means we need to make sure the compiled > files are reproducible for a defined release, not just functionally > equivalent. There is normally no need to fix things in the package > directory, as there would be new branch for fixes in the x.y.z release > like x.y.z+1 Hmm; I usually copy every builded package to packages/5_x; do you want me to keep track of the changed Packages? This should be solved by git. And it is when committing to a given repository. > I am subscribed to commits, but often the information there is terse at > best (like 'merged master to maint' but why??? ) and somehow I expected > that with the release of 5.2 the packages repository would be updated at > the same time, at least to the existing structure. kp ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
