Re: New feature for 0.6.103
Hi Ole,
On Tue, Apr 10, 2018 at 10:10:39AM +0200, Ole Streicher wrote:
> Andreas Tille <andreas@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.
ACK.
> >> 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
Andreas.
[1] https://salsa.debian.org/blends-team/website/blob/master/misc/team_analysis_tools/med_historical_data.json
--
http://fam-tille.de
Reply to: