On 10/19/07, João Pinto <[EMAIL PROTECTED]> wrote: > IMHO, the point is not about lowering the bar, is is about not having the > "bar" at all, the key is about converting the current MOTU processes which > are based on a long pipe workflow with known bottlenecks into a grid > workflow .
While I'm strongly in agreement that the issue is about developing processes that scale well, for which a grid workflow may be a solution, I'm less sure that completely open uploads are ideal: it makes sense to me that there is a set of people who are trusted to upload to the repositories, and that there are requirements to be granted this trust. The alternative may lead to claims of copyright violation, unauthorised use of patented technologies, distribution of unacceptable content, etc. Despite that, the "bar" for MOTU should not significantly impact the opportunity for others to contribute (and there is currently no "bar" to the Contributors team (1)). > The current process requires, developers which love debian/rules, but which > hate debian/copyright to be expert on both. > The current process requires end users, which love to test new software, and > which would be the best functional testers for new packages/updates to > subscribe this list in order to get "please test" notifications. IThis list > is not really interesting for those people which spend more time using > applications, than packaging them. > > The key, is about moving from single processing, to multiprocessing, > different people, with different skills can provide their specif contribute > to the final product which is, a good package, proper tested from both a > packaging and functional perspective and which will be updated according to > a policy which also meet users expectations. While this list of issues with the current process is far from complete, I believe the extended list falls into two basic categories: barriers on collaboration before a package enters the archive, and communication issues to non-developer users. For the former, a couple of solutions have been tried, and REVU has been of great benefit, but there does not yet seem to be a combination of tools and workflow that meets everyone's needs. Further, the social aspects of collaborative initial packaging can be difficult: some people maintain a sense of "ownership" of their work, and may not react well to arbitrary "assistance"; some people prefer to work in a VCS environment, and some would rather avoid it (never mind discussions as to which VCS); and some people approach packaging as an educational exercise, and would prefer explanations and comments to a working replacement. In the simple case of one developer who puts together excellent debian/rules and debian/control files (along with whatever other helpers assist these), but is having trouble with debian/copyright, requesting assistance either from ubuntu-motu@lists.ubuntu.com or [EMAIL PROTECTED] may well result in a volunteer to assist with the remainder of the packaging. For the latter, extended promotion of teams and bug tags may be valueable. I'm not deeply familar with backport and update procedures, but I suspect that the backport testers team bug list (2) is likely a good list of backports that need testing, and that bugs with the "verification-motu-needed" tag (3) is the correct source for packages currently in need of testing for -updates. > Changing from single to multi processing is not simple, it is not just about > adding new processors (in this case, people), it is about changing the > application, building reliable interfaces between processes, handling shared > resources, handling synchronization, etc. > > The documentation improvement is important because it is the entry point for > participation, however, it is not sufficient. I completely agree it's neither easy to develop processes that scale arbitrarily, nor to change processes already in use by hundreds of people. On the other hard, I believe that a sufficient amount of the infrastructure exists that changes in the documentation are sufficient to represent a change to the process. I see that there are two activities here: firstly identifying poorly advertised processes, and ensuring that it is easy for people to find them, and contribute towards the result, and secondly identifying places where our processes bottleneck, and developing solutions that reduce the impact of these bottlenecks while preserving the quality of the final result. I suspect that it is the rare case where a combination of the tools already available cannot be used to accomplish these goals. 1: https://launchpad.net/~ubuntu-universe-contributors 2: https://bugs.launchpad.net/~ubuntu-backports-testers/ 3: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=verification-motu-needed P.S. There are several tags including the work "verification". Are they all in use? Were some mistakenly entered? -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu