Re: Turning debian/upstream into BibTeX (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)
> This might be a working idea - at least in principle. We can drop the
> "Published-" prefix which was used in tasks pages but this system should
> be replaced and I would like to focus on debian/upstream issues only.
> In this scope it woul rather be:
> Reference-Key
rright!
> My problem by using this is hackish in the same way because we are
> claiming that this is an information given by upstream which is
> certainly not the case but rather Debian internal metadata.
no one forbids us to ask how they want to identify their papers in
case of multiple references ;-)
> > For the task pages, you can indeed take the first or the last entry
> I would like to drop the injection of references inside the tasks pages
> at all in favour of debian/upstream.
IMHO it is well worth keeping references visible in task pages
> The only thinkable use for such
> fields would be if we inject prospective packages with no start of
> packaging in any Vcs.
rright!
> I would like to argue that if the interest in a
> package is that low that we would not even inject some initial data into
> Vcs we do not even need publication data attached to it.
somewhat of a point indeed
> The thing is: We are trying to make Debian more attractive for upstream
> so we are just showing them that we can be helpful and work in their
> interest. For instance when distributing packages inside Debian we are
> shamelessly bypassing upstreams means to track their users. I could
> imagine a dh_registration which parses debian/upstream to create a
> debconf notice to ask the user for registration.
Great idea!
> > as for "frozen version" -- we indeed might like to generate the ultimate
> > .bib file through harvesting full archive
> To say this clearly: I'm not fully sure what might be the best solution
> and it might make sense to provide a fixed BibTeX file after Debian
> freeze. However, for the moment I prefer the aspect of higher
> flexibility of an autogenerated list for the following reasons:
> 1. The frozen list will probably a subset of the dynamic list
> 2. People might use backports / manually builded from VCS and
> are simply lacking references inside static list which are
> easily available in the dynamic list
yes yes and yes -- I was probably not clear -- we are after
autogenerated list as well, I just thought that having a
complimentary generated "ultimate" .bib could be of use as well.
> Do you see any competing pros for a static list?
e.g.
- somewhat a complimentary function to Packages and blends task pages
online -- to search for a software implementing specific methodology.
- to not require installing all analysis software on my laptop and just
fetch the static version of a file with references
(counter argument: generate on analysis and scp to local box)
but also then I could just point collaborators to that "ultimate" file
to be used by them (who might not even be using Debian)
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Reply to: