Luben Tuikov <ltuikov@xxxxxxxxx> writes:
> --- Junio C Hamano <gitster@xxxxxxxxx> wrote:
> ...
>> I am a bit worried about the 'master' being a "StGIT stack",
>> though. Playgrounds to be cherry-picked from (aka 'pu') would
>> make *perfect* sense to be managed that way (and the topics that
>> go only 'pu' of git.git itself are managed the same except that
>> I do not do so using StGIT), but I think we need a stable
>> history for the branch git.git will eventually pull from.
>
> That was my concern too, but seeing the immediate hostility
> I got about asking about the review process I decided not
> to mention it.
I do not think Johannes meant any hostility against you by
mentioning the obvious "person A sets up a repository, he gets
to decide rule for _his_ repository", implication of which is
that anobody else can do the same.
It is a completely different matter how the bits of the results
are decided to be good and bad and merged as part of git.git,
and that will be done with community input as always.
I asked Pasky to host series of patches for various reasons.
(1) I know I am less qualified than Pasky, you nor Jakub (the
three people I publicly said I consider more interested in
and have experience with gitweb than I am). If I were to
sift through the patches, I am sure many patches will rot
because of indecision. I wanted to make sure people more
interested in gitweb than myself play more active role in
its development and maintenance.
(2) It would make it easier to view and judge the impact of
pending patches if the code is used on to show various real
repositories to the public. repo.or.cz is an ideal place,
and Pasky has shown competence managing that service to the
community. A change to gitweb may look obviously correct
with just minor performance impact while code inspection,
but may have scaling issues in the real world --- he will
have the first hand experience to catch that. Anybody
could set something like that up, but I trust the three
gitweb gang more or less equally, so why not utilize the
infrastructure we already have, especially Pasky agreed to
help?
(3) I have disagreed on a handful technical issues with Pasky,
you and Jakub, but I do not expect all of us to always
agree something is good or bad unanimously, nor I expect it
would satisfy everybody in the community even if we agree
on something unanimously, if we acted as a Cabal. One
thing that is important is that the process is transparent.
I trust Pasky to be open-minded as any of us would be. I
do not expect him to start acting as a dictator on gitweb
issues and force bad technical decisions without listening
to others. I trust him at least that much. I would
probably trust you or Jakub the same way, but I do not have
to pick one single person that I trust _most_. As long as
the person who maintains the gitweb patch queue is trusted
and respected _enough_ by the community, I think that is
good enough. And this is all volunteer work. Good
maintainers are hard to find.
> I'd be interesting to see how gitweb support pans out
> given this initial hostility to inquiry of accountability.
>
> Over the years I've seen that the best support and accountability
> has been had when the maintainer is not the main contributor/developer,
> especially for shared development. Otherwise personal preferences over
> feature X and Y come into play and then things get ugly.
I understand your concern, and I think that is where you can
help the most. If you see questionable patches queued, spot
them and raise issues. We've been a friendly community, and
luckily we haven't had too many burnt bridges over personality
differences.
We have a _LOT_ of work ahead of us in gitweb area. You may
remember that there was a call-for-help from k.org gitweb master
(J. H. "warthog9", with comments from HPA) some time ago. The
installation there is heavily modified to support a large and
heavily-hit site better than the stock gitweb, but the codebase
has diverged quite a bit. We need to fold that effort back so
that (1) they do not have to keep maintaining their fork, and
(2) everybody else will benefit from their scalability work.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
