incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Fri, 03 Aug 2012 01:09:30 GMT
On Thu, Aug 2, 2012 at 6:42 PM, Ethan Jucovy <ethan.jucovy@gmail.com> wrote:
> -1

When you posted this, you may have already been aware of Apache voting
procedures, but please let me clarify in case others in the community
are not aware:

1) Your vote doesn't count. It is considered "non-binding", meaning it
does not "bind to the issue at hand". Thus, it is
advisory/discretionary/commentative/etc. Only people on the (P)PMC
have binding votes. And hopefully, they listen to non-binding votes as
important and useful input.

2) Releases cannot be vetoed. A release requires three (binding) +1
votes, and it is good to go. In short, there is no way to stop
productivity at the ASF. (vetoes on commits only sort of stop it...
the goal is to actually find a new/better solution rather than halt
the idea)

The RC1 tarball that Gary has prepared has received enough +1 votes to
be forwarded onto the Incubator PMC for release voting/consideration.

> (Note: I've been travelling recently without much internet access, and will
> continue to be for the next few weeks.)

You have a tendency to show up AFTER events have already occurred. If
you want to participate, then DO SO. Showing up after the fact and
saying "STOP. You must halt what you're doing" will not win you any
friends or respect.

> I haven't seen any significant movement on the Trac<->Bloodhound community
> issues discussed during Bloodhound's initial project proposal.  The

So? That has no bearing on this release. It is something to work on, sure.

> Bloodhound developers also seem to have backtracked on the specific
> resolutions made during the initial discussions, and haven't yet
> established any workflows or documentation to ensure good communication
> with the Trac community.  If these issues are not addressed before the

This is a volunteer community. We do not have "workflows" or
"procedures" or other monkey stuff. We try and get stuff done. That is
happening.

Is there more work to talk to the Trac community? Sure. But speaking
for myself, I find trying to get a release done is of higher
importance. It helps to establish traction and direction, which can
then help construct/attract a community. Building a community is first
priority, and *that* community can then begin to engage with the Trac
people.

(and, btw, there were no "resolutions made" at any time; only the
Board passes resolutions)

> initial release, Bloodhound's current working code and development
> workflows will gain inertia, and increase the risk of a permanent de facto
> fork.

As Gary said, that is nobody's intention.

> Specifically, Bloodhound already depends on a patched copy of Trac which
> lives in the Bloodhound SVN repository under
> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and is
> distributed with the release.  This raises a number of questions:
>
>  * Some of the files in Bloodhound's modified copy of Trac core contain
> "Licensed to the Apache Software Foundation" headers.
>  (trac/utils/tests/introspection.py and trac/util/introspection.py are the
> ones I've noticed, but I didn't grep the repository.)  I think this is
> contrary to previous claims that Bloodhound's developers would keep all
> Trac modifications BSD-licensed, and that the individual authors would
> retain their copyright over these lines of code, for the sake of keeping
> Trac's BSD license intact for all upstream patches[1].

The license headers for NEW files probably *should* have an ASF
license header on them (as an effect of the committers' ICLA). If/when
the Trac people want to accept the patches which incorporate those
files, then the various authors can agree to the BSD license *IF* the
Trac devs want that to happen. It is entirely possible that Trac will
be just fine with the ALv2 header on there (it *is* compatible with
BSD, after all).

But that is for another time, when those files get moved upstream. And
it is also based on what the Trac devs want, rather than your personal
thoughts.

> These license
> headers should be removed before a release.

There is no "should" about it. They can remain in a release from the
ASF. That is perfectly fine. They *may* be removed in a future
release, but that is for another time, another discussion.

>  * Based on the earlier discussions on the Apache Incubator list, I'm not
> sure whether cutting a release that depends on a Trac distribution
> maintained by Bloodhound developers in the Apache Incubator's SVN satisfies
> ASF's guidelines and policies.

It does satisfy ASF guidelines/policy. End of story.

>  The patched Trac distribution should
> probably be moved to a public code-hosting site like Sourceforge, Github or
> Bitbucket, instead of continuing to live in the ASF SVN.  The release
> should then point to a tag at that new location for installation, instead
> of distributing the patched Trac code with the release itself.

No. It is easier for the Bloodhound developers to work with it right
where it is, which is why this approach was selected.

>  * During the project's initiation the idea of maintaining short-term Trac
> patches in a branch-heavy Git repository or Mercurial patch queue was
> discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
>  Why did Bloodhound's developers not take this approach after saying they
> would?

As above: ease for the developers. Whether they said they would do it,
or just consider it, or whatever... the final decision was that
maintaining a vendor branch in svn would be easiest all around.

>  * What tag/revision of Trac core is the code diverging from?  Where is
> this documented?

$ BH=http://svn.apache.org/repos/asf/incubator/bloodhound
$ svn log $BH/vendor/trac

As you can see, it is based off of Trac's trunk rev 11046.

>  How often do Bloodhound's developers merge in upstream
> changes,

As you can see, the vendor branch was constructed in March and updated in May.

> and what is their policy for deciding when to merge upstream
> changes?

Whenever a developer feels like it. No policy so far.

>  * The patched copy of Trac seems to have a few-hundred-line diff from the
> official Trac distribution.  (I'm not sure the best way to measure this.)

$ svn diff $BH/vendor/trac/0.13dev_r11046 $BH/trunk/trac

About 400 lines of diff output.

Vendor branches are used specifically to track local modifications.
The process that BH is using is proper/appropriate for tracking local
mods in order to get them moved upstream.

>  Where are these patches (and their intentions, and the Bloodhound code
> that relies on each patch) being tracked and documented as core patches?
>  What procedures are in place to ensure that each core patch is being
> tracked and documented?

See above comment about "procedures".

>  * Have all of these patches been submitted upstream to the Trac core
> community?

No.

>  Where are the upstream submissions being tracked and
> documented?  (I tried several searches on trac.edgewall.org and couldn't
> find any such tickets.)  What procedures are in place to ensure that each
> core patch is filed upstream, and to track the upstream status of each core
> patch?

See above comment about "procedures".

>  * If the Trac core developers reject a patch or suggest an alternate
> approach, will Bloodhound's developers take that advice and rework their
> own code?  What procedures are being developed to ensure that this will
> happen, rather than the expedient route of continuing to rely on a patched
> Trac copy?

See above comment about "procedures".

If a patch is rejected, then we'll cross that bridge when it happens.
Until we know the parameters of the rejection, and the specific
example, then it is impossible to answer what is the best approach.

>  * It looks like Bloodhound currently depends on three upstream Trac
> plugins -- where are Bloodhound's issues filed against those plugins being
> tracked?

Have any been filed? What is the concern here? Who said they would not
be filed with the author(s) of those plugins?

I don't see the relevance of this point.

> I'm aware of only one instance where an upstream patch was discussed with
> the Trac community so far[5].  In that instance, a Trac developer said the
> relevant plugin code was in error and suggested an alternate approach[6]
> that would patch the faulty plugin code instead of working around it with a
> core patch.  This was filed but has not yet been acted on[7], and
> Bloodhound's developers did not all seem to agree that the advice from
> upstream should be followed[8, 9]; instead of patching the plugin code or
> fixing it upstream, the Bloodhound release continues to use the rejected
> core Trac patch.

So? Let me repeat: this is a volunteer community. Maybe nobody has
picked up and tried to solve that issue yet. Each developer has their
own set of priorities. If you have different priorities, then you can
work on the issue yourself. You certainly can't demand that others
work according to *your* priorities.

Again: IMO, a release is of critical importance, even there are lots
of problems with it, so I feel the community is proceeding properly.

>... snip ...
> To be clear, I don't think Bloodhound's initial releas requires a
> completely smooth procedure and infrastructure for tracking patches,
> submitting upstream contributions, and reworking changes based on upstream
> feedback.

Good. I don't think it needs any of those things.

In another year? it probably should.

> (Though the specific "technical" questions about licensing and
> code location should be addressed now.)

There is that "should" again. My response is "no, they don't".

Incubator releases are allowed to have licensing quirks as long as
there is a PLAN to get them fixed. And they MUST be fixed before
graduation. But there is no "should" at this stage of incubation.

> But those questions should be considered part of the release process.

I think you have a misunderstanding of the Apache release process, so
please do not attempt to dictate the operation of this project.

>  Partly because it's the best/only formal opportunity in the development
> cycle to make sure the upstream/downstream workflow is running smoothly.
>  And also because, after a release is made, inertia will build for just
> leaving patches in place as-is instead of waiting for upstream feedback and
> potentially rewriting features that are already working in the wild.

Thank you for the opinion. If others have time and inclination to make
this a personal priority, then it will happen.

>  So I
> think it would be more prudent to postpone the initial release until
> working first drafts of these knowledge-maintenance/collaboration workflows
> have been established among Bloodhound's developers.

That is your opinion, and as mentioned at the top of this email: it
will not stop the release.

-g

Mime
View raw message