Re: [Bug 1896] libX11 support for pt_BR

Daniel Stone wrote:
> > Daniel, could you please stop acting like a troll?
> > The approval process for the new release is very clear:
> > 1. You make a patch
> 
> Every single one of these bugs had patches attached, so this is already
> fulfilled.

OK

> > 2. You get it reviewed on demand
> > 3. You commit it to HEAD
> > 4. You request approval for the release branch
> 
> I was acting under the mistaken assumption (based on my understanding of
> how things worked from following the trail of a few bugs), that bugs
> could be filed, and patches could have 6.8.x approval requested for
> them, and be committed to HEAD and 6.8.x roughly simultaneously.  It was
> also used to signify that many of these bugs are actually quite
> important, and that getting them into 6.8.x would be fantastic.

See my previous posting from today. Remember that the Xorg X11R6.8.x
branch is also named "stable" branch: Which means: Only patches should
go "in" there which are known-to-be-good and have spend some time in
Xorg trunk without causing problems there (there are a _few_ exceptions,
for example documentation patches or trivial patches (e.g. typos) or
where the module owner thinks it's a good idea. Or when there is no
other options - like in the "nv" driver case where the whole patch has
been approved in once piece (due lack of information about the chips)
... but these are _exceptions_ which should only apply to _few_ patches
- and not _all_ of them).
Take a look at how SuSE did it: First they commited the patches to trunk
(unfortunately Egbert Eich didn't file bugzilla bugs from the beginning
so he created them later to be able to request approval for them) and
then - weeks later (actually _months_ in this case) they requested
approval. That way it's likely that we can catch any problems caused by
patches _before_ they are commited to the "stable" branch (and if they
cause too much trouble the patches can simply be obmitted until a
working solution is found - that way the "stable" branch always contains
a "safe" state.).

> > That is the order in which things should happen. Everyone has
> > understood that. Except Daniel Stone. But Daniel Stone does not care
> > since Daniel Stone is a law under himself and does not have to follow
> > any guidelines everyone else is honoring.
> 
> I misunderstood the process, with absolutely no malicious intent.  I am
> now awaiting Roland's word on how we can move forward on merging these
> patches, to everyone's benefit.  I don't believe I've demonstrated any
> malice thus far, and I'm sorry if it seemed that way, but it's simply
> incorrect.  The way I was working was apparently quite damaging, so I
> have stopped working through Bugzilla until I get word as to how best to
> do it (possibly through the proposed flags?), while keeping everyone
> happy.

My rants were only about the misuse of the approval flag system, not
about your general usage of bugzilla. Just try to get your patches
reviewed (and follow the review comments) if neccesary, then commit them
to Xorg CVS trunk, let them "bake" a few days there and then request
approval if noone screams... :)

In the meantime we should debate how Xorg can get something like a
"review" system (like mozilla.org) where people can request review for
patches - apparently there is a huge demand in such a thing (at least
for the i18n patches which went in recently).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [email protected]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)