Hi Ole,

On Tue, Apr 10, 2018 at 10:10:39AM +0200, Ole Streicher wrote:
> Andreas Tille <andr...@an3as.eu> writes:
> >
> > That's surely an option for the changelog creation.  But the json files
> > also enable creating statistics[1] using this script[2].  Its just a
> > hack and not documented (if I only had the time to do this) but just
> > parsing a set of json files is probably way more sensible than to do
> > your algorithm over and over again for all available tags.
> Another reason to create a separare python3-blends package... that
> script should be convertible to use it.

> >> If you like, I could try that as next step; then I would however just
> >> create a "python3-blends" package (to not interfer with the
> >> python3-debian package).
> >
> > May be a python3-blends package assembling (and documenting!) that kind
> > of tools (and put them on a solid technical base rather than hackish
> > scripts) would make sense.
> That is the main idea of the rewrite.
> Check out https://ole.ath.cx/blends/ which is generated from the
> blends-gen-dev source. Does it fit your needs in terms of functionality
> and documentation?

$ git clone https://ole.ath.cx/blends/
Klone nach 'blends' ...
fatal: repository 'https://ole.ath.cx/blends/' not found

> > But I think, sticking to the approach to store the dependency data in
> > some sensible way (not necessarily inside the source package) is
> > reasonable if you want to look quickly at historic data.
> We already have git, so creating a function that returns a
> `blends.Blend` object based on some git tag (rep. Debian version) is
> straightforward with `git worktree` and also (since the blends source
> packages are rather small) quick. And has the advantage that you don't
> need to maintain an additional json file. You can just generate it on
> the fly ;-)

I confirm that I understood that it is possible to do this.  However, I
can not imagine that whatever kind of diff between tags will be used
this is faster than just reading a json file.  In addition I would need
to "fake commit" pre-version control data into Git (yes, there were
releases of Debian Med before I started using SVN).  These are now
simply stored in json that's aggregating the data I want to display[1].
I admit this json is of different nature and could be used in connection
with any different method to obtain the Git-based data.  I'm just
afraid about changing something that is *really* rarely used and simply
works just for the reason to make it more elegant.

Kind regards




Reply via email to