Hello, I have not seen it in the Debian policy document, yet, but at least for the packages I co-maintain with Ubuntu developers myself (all outside of Debian Med if I am not erroneous) and from what I read on the lists, it is common practice to just extend the debian/changelog file. It is never shortened. The idea behind this is that we all steadily improve the package, and knowing about the changelog allows to estimate the gain of functionality that may be observable in the one or other distribution. And of course it also helps to pinpoint to the one responsible for the good or the bad, without a dig in the repository's logs. One possible effect is that the debian/changelog is already fairly long before it first hists the Debian server. Nobody should mind.
Another source of packages that I would want to render you aware of are those packages that we create for ourselves. Those, that are never truly meant to be uploaded to the servers. I personally for instance create a Debian package for about everything that I evaluate locally. And a basic package is fairly simple to create, so I just do it. It does not cost much extra time. And finally, the final package is just so much easier to get removed from the disk again after the evaluation. And I do not need to fiddle with the PATH too much. In most cases, such packages never go anywhere. But sometimes those are submitted to the Debian Med repository. And we just had the case, that for a recent release of T-Coffee, the structural alignment program TMalign was suddenly of interest. This was one of those "should be in Debian Med" packages that is kind of there but not really ready for an upload. The ITP pending because of a missing license file and then forgotten. It was then found by Tim who has then with support by Andreas completed the packaging. Lovely. In my mind, the debian/changelog file should then remain intact, i.e. not be resetted to a "Ininital release (Closes:..)" kind of minimalist version. The package had a previous life also outside the distribution. And we would weaken our community when we just forget about that initial development time. That reason not to upload may be technical or due to a temporary lack of interest. The package nonetheless should not forget about its history. The issue is strategically important for me because of yet another reason. With an increasing adoption of bio-IT in the drug development process, we are likely to see many more tools that are not redistributable for Debian, but that allow for a local compilation of the sources. For those tools, and for instance Rosetta is not something that one could too easily ignore, a support through Debian would not get any further than to our subversion repository, i.e. the sharing of the debian folder with all the build instructions, with its build- and runtime-dependencies. NAMD and VMD are other examples. I do not know for the latter, but for Rosetta I know the community support to be excellent, shared between academic groups around the globe. I want those experts to consider Debian more for their development and for their sharing through it. Hence, let us experiment with an exchange of package build instructions, let us strengthen our Debian Med developer portal's code sharing mechanism and let us accept the debian/changelog files as an essential brick towards that. Best, Steffen (who after all this writing has finally decided to upload the sources for his Rosetta package) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
