Just slightly amended, this proposal was approved today at the MOTU meeting:
STANDARD WORKFLOW:
LP is where needs-packaging bugs are created to document the desire for or
intent to package something.
Once someone starts working on a new package, they assign the bug to
themselves and set
Scott Kitterman [EMAIL PROTECTED] writes:
STANDARD WORKFLOW:
LP is where needs-packaging bugs are created to document the desire for or
intent to package something.
Once someone starts working on a new package, they assign the bug to
themselves and set status to In Progress.
Once an
On Fri, 09 Nov 2007 00:16:26 +0100 Reinhard Tartler [EMAIL PROTECTED]
wrote:
Scott Kitterman [EMAIL PROTECTED] writes:
STANDARD WORKFLOW:
LP is where needs-packaging bugs are created to document the desire for
or
intent to package something.
Once someone starts working on a new package,
think that source packages and running debuild -S is concept
hard to learn. I agree that we still need it (we'll see when
NoMoreSourcePackages is going to be implemented), but I don't think that
it's problematic and should be inherent to the review process.
People will learn it quickly, if they use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(I knew i'd missed something!)
And like Stefan, I'm not convinced that moving to a BZR-based system
would actually solve any of the underlying problems.
At the autobuilding, perhaps build when each lot of changes is made.
Cheers!
Sarah Hobbs. aka
MOTU or hopeful can tell them. But even if the hopeful is getting
*some* feedback, that's probably better than nothing.
Things, that I'm really missing in revu though, and that would be a great
plus
for the review process:
* for packages already in the archive, revu sucks. Also for merges
Hello everybody,
some of you might have heard of the CodeReview spec or might even have
had a look at https://wiki.ubuntu.com/CodeReviewSLA - The spec was now
approved and is a new proposal to attack our problems with reviewing NEW
packages.
We had several discussions at UDS, and to me
the new process for
universe in a good shape soon.
To understand the whole problem, I'd first of all like to take a look behind
the idea of the reviewing process:
Imho the review process currently serves four goals:
1) get more software into ubuntu
2) keep the (new) software in ubuntu in good
