This reply is marked to the start of this thread, but directed to all followups that has been written so far. It expresses my general opinion on that matter and is therefore not directly directed to Emmet. However, I'd like to thank Emmet nevertheless for his input on REVU.
"Emmet Hikory" <[EMAIL PROTECTED]> writes: > My view of REVU is that it currently provides the following services: > > 1) dget'able respository for packages > 2) Automated keyring check for uploaders > 3) Automated execution of lintian and linda > 4) Provision of URLs for easy package review > 5) Comments engine for packages Scott Kitterman added to this list: > 6) Emailing of comments to a mailing list > 7) Online diffs between uploads, even ones with the same version number > 8) Automatic unarchiving and association of previous uploads with a new one > 9) It's fast > 10) It requires the use of no tools not standard to Debian. Thank you both for the interesting compilation of REVU feature. Emmet goes on with an alternative workflow: > > 1) Someone opens a bug with a upstream link and adds the "needs-packaging" > tag. > 2) A packager marks the bug "In-Progress", and self-assigns > 3) The packager prepares an initial revision, optionally commits to a > BZR branch, and uploads to the PPA. The bug is closed in the > changelog. > 3) The packger adds a comment to the bug with a link to the PPA > location, and submits for sponsorship in the usual manner > 4) Sponsors review, and leave comments in the bug > 5) The second positive sponsor review results in an upload, and sets > the status to "Fix Committed". In general, I like the idea of stressing the use of the 'needs-packaging' bugs. They often contain links to REVU uploads, and it feels natural to join these resources. Maintaining a source package in bzr is as well a nice idea. However, since it seems that we cannot agree on the exact way how to package a software, and our current tools for managing packages in bzr (read: bzr-builddeb and hct) definitely need a lot more work for that, I don't think this is feasible. I tried compiling the different ways of managing packages in VCSs, which can be found at [1]. The feedback however was, that there is a big disagreement on the exact mode to be used when packaging software. [1] http://wiki.tauware.de/misc:vcs-packaging I think we can therefore safely conclude that the least common denominator for source packages are the source package format mandated by Debian policy, read: *.diff.gz, *.orig.tar.gz and *.dsc. Which brings us back to the reviewing problems we had before. I don't think it matters a lot if the packages are hosted by REVU, the contributor, a launchpad PPA or whatever. Leaving this choice intentionally open brings us extra flexibility! Emmet Hikory wrote additionally: > With the exception of #3, I believe these requirements are soon to > be met by LP itself, and would suggest the following workflow as a > LP-specific alternative to REVU: Again, this is not directed at Emmet specifically, but to the whole MOTU community: I'm a bit sad that there seems to be a general attitude among MOTUs that we get the tools we are working with crafted by either Debian or Launchpad. This raises the assumption that there is not much technical understanding needed for packaging software in ubuntu. I do not think this is true. I rather think that we should focus more on crafting tools which aid us in the daily workflow. With 'us' I mean 'we, the community of Ubuntu Developers'. Let me rethink about past projects: * (obviously) REVU * sistpoty's mergeWebTool http://tiber.tauware.de/~sistpoty/MoM * lucas multidistrotools * Adri200 + Lutins DaD: http://dad.dunnewind.net/ * ... I do think there is still a lot of room for crafting dedicated MOTU tools. The Project [2] is of course a good start! We should stress it more and work more on extending those tools. As far as I can see, it is a branch of small scripts for day-to-day tools for Ubuntu Developers. I expect that many fellow developers have local branches on their computers where they hack their own tools and merge them back to the trunk from time to time (where it fits). I imagine that we can also craft wepapps to aid us, like the examples I listed above! [2] https://launchpad.net/ubuntu-dev-tools And please don't misunderstand me. I'm not saying no to launchpad. Au contraire, I rather say, lets craft tools that fit and extend launchpad. The launchpad guys are very open for suggestions and collaboration with other open source projects. If we need interfaces, I'm sure they can help us in many ways, even if its 'just' with advice. Thinking further about it, I think this is also a great area, where our hopefuls can get into action! You absolutely don't need any privilege or permission or anything to craft tools like I listed above. I think this is also a good way of showing interest and in the end, qualification for Ubuntu Developer status! Consider starting or contributing such a project, it's really worth it! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
pgpvn03QRZGBo.pgp
Description: PGP signature
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
