Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

[Emmanouil Kiagias <e.kiagias@gmail.com>]

Hello Andreas,

On Wed, Jul 31, 2013 at 11:55 AM, Andreas Tille <andreas@an3as.eu> 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> <maintainer@ema.il>  <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