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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Thu, Aug 01, 2013 at 12:17:51AM +0300, Emmanouil Kiagias wrote:
> >  -- <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 *.

I trust you in this but I think this is the moment where we probably need
to prepare some kind of official blends-dev package.  I tried to copy
Makefile and rules into place but

   make -f /home/alamagestest/Projects/blends-gsoc/devtools/Makefile

fails on my side. ;-)

IMHO we should apply the following workflow:

  1. Create code for a real blends-dev package (say version 0.7.0) which
     puts Makefile and d/rules into the places where they currently are
     in blends-dev.
  2. I will build the package, install it on my machine and can run the
     code in current Blends unchanged (because these just include the
     files verbosely)

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

Perhaps compression is just stupid.  The tarball will be compressed
anyway so there is no real win in double compression.  Lets just stick
to the json files.

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

... otherwise you wouldn't be a GSoC student. ;-)

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

Cool.  From a quick view these files look very familiar.

> For my tests I used debian-med.

Me to because I'm very familiar with it. :-)  I also tried debian-science
which looked good as well.

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

Uhmm, stupid!  Thanks for the hint - I injected the whole content as tag
because I have no idea how to roll back to a certain state in SVN, tag
this and get the latest trunk status (= "master") again.  I think once
we have implemented the new blends-dev it is perfect time to switch to
git because than I do not need to rewrite my graphing script from SVN
tags to Git tags but rather can use the JSON files.

> 1.13.3 are not tagged).

Sure, that's unreleased trunk.

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

Fine.  As I said it would be great if you could create some blends-dev
package to let us do things on "neutral" pathes as it will be
implemented later anyway.  SO I will be able to test your work more
easily.

Kind regards

       Andreas.

-- 
http://fam-tille.de