> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
