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

[Andreas Tille <andreas@an3as.eu>]

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

> The steps we need are the following:
> 
> 1)First a ./task_diff --status-dump should have been called in order to get
> a jsondatabase containing the dependencies of the current release.
> 2)Then once a new release of a blend is created and a new entry in the
> changelog with the new release is added,  ./task_diff --compare can be
> called and its stdout with the changed dependencies can be added into the
> new changelog file under the latest(new) release.

This is what I have described with other words above.

> 3)Finally ./task_diff --status-dump should be called again to override the
> previous jsondatabase with the new releases dependencies.

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.

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

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

> * The ./task_diff --compare with the change dependencies should also be
> called manually / automatically? if automatically from where
> makefile/rules/VCs hook?

None (as described above).
 
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.

Hope this helps

      Andreas.

-- 
http://fam-tille.de