[Piuparts-devel] The piuparts development cycle (was: Re: Bug#688736: w3c-linkchecker: modifies conffiles (policy 10.7.3): /etc/w3c/checklink.conf)

[Andreas Beckmann]

On 2012-09-27 21:32, gregor herrmann wrote:
> On Thu, 27 Sep 2012 18:45:06 +0200, Holger Levsen wrote:
> 
>> Hi Gregor,
> 
> ¡Hola!
>  
>> On Mittwoch, 26. September 2012, gregor herrmann wrote:
>>> Maybe I would even offer to do such "maintainer-approved NMUs" if you
>>> or Andreas told me "please upload commit 12345 from the develop
>>> branch to experimental as version 0.(n+1)~expY" every now and then,
>>> if that helped :)
>> IMO we should just upload to unstable more often. (And Andreas is a DD now or 
>> will be soon.)

My piuparts development cycle looks like this:

generate idea && fork()
HACK:
hack some code
run on selected examples || goto HACK
check the result || goto HACK
write a bug template
report a bug
WAIT:
run on some larger portion of the archive
 - manually reschedule interesting packages
 - wait for automatic rescheduling
wait for the next piuparts-report run
check the logfiles
are the false positives below threshold? || goto HACK
report some more bugs
do I like the result? || goto HACK
HACK_KPR:
do I want a known_problem report? && write it && goto WAIT
do I like the result? || goto HACK_KPR
is it worth keeping these changes? || goto END
polish up the patches && add Signed-off-by && goto WAIT
is it still working? || goto HACK
push patches to Holger
END:
report more bugs
join()
pull/merge/rebase/...
GOTO 0

Don't ignore the fork/join part! There are several of these things going
on at a time usually.

And, yes, I should think about adding a post-feature hook after END:
  test -n $(git diff last_tag.. | filter) && \
      dch -r && debuild && debsign && dput
But don't expect to see the code before seeing the first bug report :-)

There is only one set of regression tests for piuparts, it's the
archive, and full rechecking takes a bit ... (but a full recheck is not
required for a new feature is to be published).
And I like to report bugs early because piuparts-analyze will move them
to bugged/affected and I only need to look at the remaining fail logs.

Perhaps we should document this somewhere ... "piuparts is being
developed while continuously checking the archive. So expect to get bug
reports discovered by experimental features before the code has been
pushed to the git repository."

> Sure, that would be the best option; and I'm happy to see Andreas as
> a DD soon!

:-)

Andreas

PS: I just mad a nice drawing of my git usage for piuparts on a postit,
I should redraw this a little bit larger. But still on paper. :-)