git process

Mon Oct 8 16:52:40 GMT 2007

I think you are missing the point that this removes
responsibility from the release manager and does not increase
his or her control.  The RM just becomes a person that cuts
tarballs.  You are still thinking in terms of centralized
development.

This email provides some more background:
  https://lists.ubuntu.com/archives/bazaar/2006q4/018309.html

I arbitrarily assigned two people to each role in the pre-receive
access controls based on past roles or interests

  * repo admins (metze and myself)
  * Samba 4 RM (abartlet & jelmer)
  * Samba 3 RM (volker and myself)

Two is a good number because it gives you a backup.  But in
reality a backup is not even needed.  There's this insane
need to have trunk where all your changes are safe and sound.
So whether for mental comfort or whatever reason, I conceded
on the shared repository in spite of the fact that I think
it is a social mistake.

But suppose I'm off line for a week.  Nobody technically needs
to push to *-test except for this craving to have a central place
to pull from.  You could collect all the request to pull into
your "changes-for-jerry-when-he-gets back tree" and then
I can just pull that tree when I'm back online.  In the meantime,
no changes are lost.  In fact, your *-test tree is just a valid
as anyone elses.  But to alleviate this unfounded fear of a
bottle neck, Volker can be responsible for pulling changes
while I'm away.   Or both people can as long as both follow
the RM-creed (noted below).

Please understand that the RM != leader (technically or socially).
There is nothing special about the person fulfilling the role
of RM except that the RM:

* Promises abide by the majority consensus and not short circuit
  the review or pull process into *-test.

* Can push *-test and *-stable to the shared repo for everyone
  else to see (which I already said is a conceptual stumbling
  block).

* Updates release notes & cuts tarballs.

> Why can't we just have a development process where 
> everybody uses git, where all team members have full
> write/push-access to the main development and to the
> main release tree (just like we now have (as of 3_2_0)
> and where the release manager (aka jerry) in addition
> pulls at will from project/petproject trees of individual
> team members and external developers.

Because that model requires that RM == Developer.  And frankly
it is not working.  IMO SAMBA_3_2_0 has too much churn to be able
move to time based releases.  People check in what they want,
whenever they want.  SAMBA_3_2 and SAMBA_3_2_0 for the most part
treated as an "unstable" tree.  We have a process of performing
dual commits while only in the drafting stage of of features.

Personally I think the *-unstable tree is also a mistake.  But
that is what people want.  I would much rather have *-test and
*-stable trees and run *-test on the buildfarm, but people
have this inherent need to check things in upstream *now*.  I
think that is a mistake rooted in CVS/SVN indoctrination.
I also think that, while the buildfarm is indeed useful, we
are letting it control our workflow and not the other way around.

So let me clear the air on a few things that may be confusing.

a) All commits should be considered equal.  The line between Team
   and non-Team should only be in regards to project leadership,
   not development.

b) The requirement that the RM is a Developer in order to qualify
   code as ready to release should be removed so that the RM
   position is much easier to reassign.  Or maybe even at
   some point done away with entirely.  If you build a better tree
   than I do, quality, not divine right, should prevail.

c) And finally, in my opinion Samba development is stagnating
   because we neither provide the tools nor the community to welcome
   in new ideas or developers.  For example, this is why IMO Samba's
   participation in SoC has only achieved a fraction of the benefit
   we could have. I for one an willing to loose my own self-perceived
   importance to the project for what I believe will be to Samba's
   benefit.  The ego benefit we get from being of the "Team" is all
   smokes and mirrors anyways.

What I'm asking for is more of an opening of Samba development than
a simple change in the SCM toolchain.  That is why I've spent the
last year thinking about this and working out different scenarios.

cheers, jerry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCmBXIR7qMdg1EfYRAqOEAJ4kEqvsBUVt5ykngLy3oQoXC0FWjwCcDCCg
RewI7Tn08b2VormXFkA7fgA=
=pTHc
-----END PGP SIGNATURE-----