Hmmm, I have no idea what you mean when looking for a name.
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).
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@example.com> <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
3. Create the orig.tar.gz containing the finished d/changelog.
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
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 amCool. So you might have something new to learn and may be bring some
> not so confident of how the changelog entry should be performed.
new ideas in. ;-)
> So myI hope it became clear in my algorithm above that we should generate it
> questions are:
> * Will the --status-dump be called manually or automatically somehow(when a
> release is tagged in VCs?)
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*.
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.