[haiku-development] Re: Redefining the commit rights
- From: Enrico Weigelt <weigelt@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 14 Sep 2010 01:48:45 +0200
* Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx> schrieb:
Hi,
> However, aving more contributors can also be a bad thing, with
> some of the concerns I heard in past discussions :
> * Granting access to people that can't keep the code quality as good
> as it is
> * Granting commit access is the same as granting 'project member'
> status with vote right
when haiku once moved to a proper DVCS, eg. git, that problem almost
goes away by itself, by:
a) give contributors write access only to their own namespace
(can be easily via hooks in git)
b) only the real core devs (those who know the system very well)
have write access to the main namespace and merge only on
request and when the changesets conform their quality requirements.
c) optionally a third role, tree-maintainer, could be introduced,
which take do things like merging changes that had been voted
to go in.
Of course, this all implies folks to really use branches (and NOT
everybody committing to trunk).
> This could be used for
> contractors from outside the project, that could take part into the
> development work for a thing they are paid on, without necessarily
> connecting to the Haiku community. This never hapenned before as Haiku,
> inc chose to pay only people that were core contributors. But I believe
> it could work, also for people coming/getting paid from elsewhere. The
> problem with this is we need to answer a question : who gets vote rights ?
IMHO, these aren't really different cases. All contributors push
their changes into their own namespaces (each one is responsible
for maintaining its own namespace), and they can trigger a vote on
their changes to come into the main tree.
<snip>
> What we need her eis some kind of 'playground area' or sandbox where
> people can put their patches, I believe svn trunk would be a good place
> for that, with the core committers working on porting these fixes to
> the stable branch.
As said above: each contributor (also the coredevs) has its own namespace,
where he can push anything he likes. And there should be one branch per
issue, maybe also adding the ticket id as branch name prefix. If some
branch becomes ready, there'll be a vote. If the vote is won, the branch
gets merged into mainline and can be removed when not needed anymore.
> When an alpha version is released, the next one should be branched
> seconds after, and the integration of features from trunk should
> start there.
Each release simply gets its own tag. If there should be some additional
work directly ontop that release (eg. for quick bugfixes), a maintenance
branch is forked-off the tag, which then ends up in an sub-release (with
own tag again) when everything's done.
BTW: bugfixes should (in very most cases) always done on the earliest
release (of those still in maintenance) where the bug happened and
later subsequently rebased and merged to newer releases and mainlines.
> * More formal mentoring : there are two types of patch committers :
> people that want to become commiters, and people that just hacked things
> up to get them work and decided to release their patches in the hope it
> would get useful for someone else. We have no way of differenciating
> these patches in trac.
Simply add a new field for it. Tree maintainers and other folks can
then filter on that.
> Adding a field to request review on a patch on trac would be a solution,
> but compilcates the process of submitting a patch (less checkboxes
> makes less confusion). Assigning a mentor to people that request it
> would be another possibility.
There could be another bugwrangler role, which takes care of sorting
those things and maybe mentor new people.
> * Keeping track of patch submitters : if someone submits patches in
> different areas, these patches may be reviewed by different people. We
> are not keeping track of the work done, so none of the reviewer may see
> that there was a lot of other good patches done before and it is time
> for commit access allowance.
Those cases should be discussed on the maillist. In my proposed model,
only a relatively small number of people are in actual changeset
voting, and they would learn in time which other contributors are
ready for getting coredev or treelancer role granted.
Oh, BTW: remember - there should be no (text-based) patches in the
tracker anymore, instead having everything as branches in the
individual contributor's namespace.
> * Looking out of the code : writing code is not the only way people
> can contribute to Haiku. Designing flyers and other graphical work,
> writing scripts, working on the websites and online tools, moderating
> the IRC channel or the forums, writing documentation and other articles,
> triaging tickets in trac are tasks that could be granted to people not
> knowing C++. Some of these tasks could also grant you a vote right.
Perhaps there should be different kind of vote rights, for different
areas of the project (eg. sourcecode is completely different from
media stuff, documentation, etc). These things should also be kept
separate in the VCS.
> * Keeping some low hanging fruits for newcomers : easy tickets get
> fixed so fast by the most active commiters that newcomers get no chance
> to look at them. Maybe we should refrain from fixing these and mark them
> as easy to help people getting started with Haiku. This means these bug
> may be left open for a longer time, however.
Add a new trac field and proper fields for that.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@xxxxxxxx
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Other related posts:
