[haiku-development] Re: Moving away from Subversion (pt 3)
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 14 Sep 2010 09:09:35 +0200
Hi,
Von: Wim van der Meer <wpjvandermeer@xxxxxxxxx>
> On Tue, Sep 14, 2010 at 11:47 AM, Enrico Weigelt <weigelt@xxxxxxxx> wrote:
> > * Wim van der Meer <wpjvandermeer@xxxxxxxxx> schrieb:
> >
> >> Personally I don't like the dictator style workflow that the
> >> linux kernel has. Haiku's mentor style workflow where developers
> >> make commits that are commented on by others is much more
> >> friendly and I don't see why there is a need to change that.
> >
> > What's the exact difference between LT's and mentors ?
> > Why not just letting some LT's also work as mentors together
> > with "lower" devs in the same branches ? Or maybe even set up
> > mentoring groups which have their own repo or namespace ?
>
> The difference (as I see it) is that LT's have a dictator above them,
> while mentor's do not. Also everyone can be a mentor if he so chooses,
> but LT is a more formal role (unless we want to formalize the mentor
> role?). IMO, with a small (active) group of developers it doesn't make
> a lot of sense to me to use too many formal sub-roles. But please
> correct me if I am wrong.
I am with Wim here.
On a related note, I just wanted to get it off my chest, that this whole
discussion about switching to a DVCS is besides the point IMHO. If there are
technical reasons (robustness of the tools), that's of course something else.
But with the specific problem in mind that patches linger in Trac and it's too
much hassle for non-committers to maintain their work, let me throw out some
ideas that I think would help:
How about status symbols besides patches in Trac which work via BOM: One status
symbol for a passed style-guide check. Several symbols which confirm that the
build (of the various platforms and GCC versions) is not broken after applying
the patch (and that it still applies cleanly). Then a button visible to users
with developer trac priviledges "Add to commit queue" which triggers a commit
bot.
How does this help? The status checks are mostly for the patch supplier: He/she
can adjust the patch as long as necessary until it passes the automatic style
police. It will also show that the build itself is not broken. Then as a patch
reviewer, I can concentrate on the only thing really required from me: Review.
When I think the patch looks fine, I can simply hit the commit-queue button and
be done with it. Right now I have to
* Review the patch
* Download the patch
* Apply the patch (may already fail, go back to ticket, inform supplier)
* Confirm the patched sources build, preferrably at least on multiple GCC
versions
* Test the behavior of more involved patches
* SVN commit the patch
* Go back to the ticket and close it, mention the committed revision
The above list would reduce to one item for a large number of patches, some
larger patches would require me to download and apply and do some testing
before I can confirm it works. The list would still be reduced.
Technically, this requires much more integration between BOM and Trac, and Trac
needs to trigger style checks and "custom" builds when someone attaches a
patch. Probably a lot of work. The WebKit project has tools, but they use
Bugzilla for this. They also have specialized review tools integrated in their
Bugzilla which make it easy to comment on specific lines of a patch. I could
live without those at first, but getting rid of the mundane tasks would be a
relieve already.
How will switching to another VCS help with any of this? Isn't this more
towards a solution or at least significant improvement to the original problem?
We can still switch to a DVCS, if it improves the situation even more, but the
above should have higher priority IMHO.
Best regards,
-Stephan
Other related posts:
