Hello Andreas,
On Wed, Jul 31, 2013 at 11:55 AM, Andreas Tille <[email protected]> wrote: > Hi Emmanouil, > > On Tue, Jul 30, 2013 at 10:31:40PM +0300, Emmanouil Kiagias wrote: > > OK, regarding the changelog entry, how do you want it to be called?(I am > > looking for ideas). > > Hmmm, I have no idea what you mean when looking for a name. My bad, wrong phrase, with *called* I wanted to say *executed*. > My idea is > something like this: > > 1. Changelog is edited in VCS manually looking like this: > > <blendsrc> (<version>) unstable; urgency=low > > * <manual entry 1> > * <manual entry 2> > * ... > * <manual entry n> > > -- <Maintainername> <[email protected]> <datestamp> > > 2. When running the job that creates d/control and taskdesc files we > also create the changelog diff and insert it simply past > <manual entry n> > It might be reasonable to flag the automatic entry inbetween > > * start automatically injected changes * > * end automatically injected changes * > > or something like this. It might even make sense to commit this > automatically createt changelog into Vcs for UNRELEASED versions > and just replace the stuff inbetween once we run the job the next > time. > > 3. Create the orig.tar.gz containing the finished d/changelog. > > I changed the Makefile/rules files and now changelogentry(a first try) is done as you describe above. I compare the latest release with the previous and I add the ./tasks_diff --compare stdout between the lines * start automatically injected changes * / * end automatically injected changes *. > > IMHO we need a versioned database because we can not really drop the > previous JSON data after each run. Assume we are just targeting at > "UNRELEASED" distribution and just create the tarball to check how it > looks, perhaps doing some unrelated other changes (like bumping > standards-version or so). We always need to keep the status at least of > the previosly released version and I think the best way would be to have > a file say dependency_data_<previous-version>.json around. > > I could even imagine to just keep them all like in dir like > > dependency_data/<versions>.json.xz > > which will probably not waste a lot of space and I think I mentioned > before that this would enable easy graphing of development of the tasks > dependencies over time. > > OK. in the code I assume that there is a directory dependency_data/ and there exist the dependenciesjson files by the name: <blendname>_<version>.json (for the moment I do not compress them) > This is my first time dealing with makefiles/package releases etc so I am > > not so confident of how the changelog entry should be performed. > > Cool. So you might have something new to learn and may be bring some > new ideas in. ;-) > > :-) , it's always nice to learn something new > > So my > > questions are: > > * Will the --status-dump be called manually or automatically > somehow(when a > > release is tagged in VCs?) > > I hope it became clear in my algorithm above that we should generate it > at the same time when we are creating d/control + taskdesc > automatically. IMHO that's logical because this is the time when we > are potentially changing *something*. > > Yeap, your algorithm was very clear :-) and it really helped me > > For the moment the only problem I see is some hen-egg-problem because > when you need to create the first changelog-diff there is no JSON file > to compare with. So you either could fake some such files for the > previous release or - in case we decide to store json dependency files > for all releases it might be pretty cool if you could find some way > to restore such databases from old d/control files in Vcs. This would > be quite in line with my idea to graph the development of dependencies. > > A first approach for the hen-egg-problem is the script dumpsTags. The script gets the tags directory of a blend and for each tag(version) it dumps a <blend>_<version>.json to a given directory. It a first simple approach and seem to work for svn. I tried it with debian-med and it worked. For example: ./dumpTags blends/projects/med/tags/ testdump/ For my tests I used debian-med. Using the above script I created a folder dependency_data/ into med-bio containing all the json files from the tags(one per version). Then I tested the changelogentry for med-bio/1.13.1 (latest 1.13.2, 1.13.3 are not tagged). The changelog entry for med-bio/1.13.1 automatically creates the debian-med_1.13.1.json and (we assume that there is also the previous debian-med.1.13.json) compares it to the previous release 1.13. The code for the moment it creates a debian/changelog.new file which is also included into the orig.tar.gz. This is a first try. Tomorrow I will perform more tests on this I clean up this part of code to make sure that everything works properly. Kind regards Emmanouil
