Hi! Am Dienstag, den 06.05.2008, 23:47 -0500 schrieb Lukasz Szybalski: > > > I'm not sure what would need to happen process wise to enable > > > Developers to use wiki page to collaborate their readme and > > > readme.debian. > > > > Making DD's life easier would unsure quick adoption. May be : > > - A set of scripts for the DD to retrieve and update the wiki page. > > (that might later be included in debhelper) > > Making a download script wouldn't be hard. Upload on the other hand > would have to somehow be automated triggered by some event. Update > script needs access to the wiki files. aka needs to be run from the > same server. How would I get access to wiki server if one wanted to > implement this? Erm, the wiki is running on a restricted machine, only a few debian developers have access there. And I wonder, why does it need access to the wiki files? Directly overwriting is a very bad idea because it's working around the version control used by the wiki. > How is the package released? If new package has a new release > number/version number we could track the new package and know to > upload the readme file. If I somehow would be able to tell there is a > new version I can overwrite the wiki page. Like said above, overwriting is an extremely nasty and dirty approach. > > > > http://wiki.debian.org/pkg/ant/README.Debian > > > > > > I'll modify the script to make it so. > > > How things change from stable to testing?, maybe > > > http://wiki.debian.org/etch/pkg/ant/README.Debian or > > > http://wiki.debian.org/stable/pkg/ant/README.Debian ? > > > > The page should be for development (i.e "unstable") only since > > DebianStable package is unlikely to be updated for a mere README update. But stable users also want to be able to view the README files. It doesn't help with the usual approach of unfortunately way too many maintainers that stop caring about their packages outside the scope of unstable only. > Good point. In that case I would upload stable/testing with readonly > access and ustable would be the one people could modify, allow > somekind of suggestions. How would you put that into the general workflow of package maintainers? They are already flooded with various different ressources where they are expected to pull informations from, adding to that doesn't make the system better but worse because people definitely will start to care less. > What is the difference in structure in pool/main/c/coreutils/current/ > vs stable,testing,unstable? There is no /current/ in the pool, if you really ask with respect to the pool. The references are in the Packages files from the dists/release directory. The pool is just what the name means: A pool to put things into. No structure there (besides from splitting by source package name to not have thousands of files in a single directory) So long, Rhonda
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil