[haiku-development] Re: Change patches workflow [was Final Set*UIColor Patch, Version 3e]

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Nov 2015 07:06:57 +0100

On Sun, Nov 29, 2015 at 07:54:41PM -0600, looncraz wrote:

1. Submit a proposal through the dev mailing list / BugTracker

A dedicated tool such as gerrit would be more suitable.

2. Await community feedback re worthiness and implementation basics

"community feedback" can often become a lot of bikeshedding. mmu_man can
comment on how he tried to submit a patch to QEmu, and they asked him to
rewrite half of their code first.

3. Initial patches should be review incrementally for implementation of
design
4. A vote is held to assign responsible reviewer(s), volunteers welcome

A vote for each submitted patch? That's a good way for things to never
get merged. After two weeks people will stop voting because the process
is too boring, and/or people will get assigned patches they don't care
about (which is not motivating to have a look at those).

5. Submission candidate patches are reviewed for bugs, design issues
6. Bugs are fixed, reworkings made
7. Patches are reviewed for style violations and cleanup
8. Style violations are repaired exclusively by originating author(s).

If he didn't move to other things already after the time it took to go
through the first 7 steps. What if someone else wants to takeover the
patch? Are they not allowed to fix the existing one?

9. Final review
10. Commit to experimental branch
11. Experimental branch patches moved to master after community testing

This means you expect "the community" to run the experimental branch.
Two possible outcomes:
* The master branch is useless, because everyone runs experimental (same
thing we have with our 3-year-old release currently). Everyone expects
the experimental branch to be stable and complain when it isn't, or:
* Everyone uses the master branch, and 50% of bugreports get closed with
"already fixed in the experimental branch".

Style fixes are nearly LAST, but glaring issues are pointed out when
noticed, which will help eliminate the duplication of effort and submitter
frustration.

You can work any way you like. You can post small patches whenever you
have something working and ask for early review. Expect people to point
out both style and design issues - why should they ignore style issues
as they spot them?

As a submitter, try to find a good balance: submitting a patch too often
will make the devs think "oh no, not again", especially if it doesn't
include all the feedback from the previous run. Not submitting often
enough, you risk your next iteration to be in a wrong direction in a
fundamental way, which means major rework for you and frustration on
your side.

P.S. I haven't forgotten about expanding my style checker and sharing it,
its current design is actually quite a bit more flexible than the existing
tools in some regards - especially since it can parse diffs or patch files
directly. In fact, it dawned on me a few days ago that a text-parsing
system I've used somewhat frequently (written in PHP) may make a nice
foundation for a really nice online style checker. I already requested
permission to use it (it's very much closed source), no word back yet, but I
don't think it will be a problem.

Thanks, looking forward for it!

--
Adrien.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 11-2015