Discussion:
[Trac-dev] New Trac based project
Ian Wild
2011-12-02 12:32:20 UTC
Permalink
Hi All,

As some of you may already be aware, earlier this year WANdisco[1]
approached members of the Trac development community with a view to working
out how we could most effectively invest development time into the project.
We plan to use Trac as a basis for a defect tracker supplied with our
uberSVN product[2]. Our goal being to develop a tool which can compete
out-of-the-box with other non-opensource defect trackers that have gained
popularity in recent years.

The resulting discussions were interesting and culminated in the idea that
we might get the most done in the shortest time by performing a 'friendly
fork' of Trac and running that as a separate FOSS project. It was felt this
would present the least risk for everyone involved while still leaving
options open for future collaboration. Furthermore, having seen the success
that joining the Apache Software Foundation brought to Subversion, we felt
that this model could reap many benefits for the community of Trac
developers and users and wanted to explore that further.

Since then we've been looking to bring together a team who could drive
these efforts and I'm pleased to say that in the last couple of weeks that
has finally been realised. Not only do we now have a full time lead
developer working out of our Sheffield (UK) office, with support from a
number of colleagues who will contribute significant amounts of time and
energy to this work, we are also recruiting additional freelance developers
to work on this project as independent committers*.

We have a strong and passionate team who will do all they can to make this
a success. However we can't form an entire opensource project on our own.
Our first goal is to enable a community to come together which has
the strength and depth to take this forwards. While the Apache move is an
important part of that, no less important is support from the general Trac
community and especially the current and past committers who have done so
much to get the software to where it is today.

I want to be clear that our intention is in no way to undermine the current
Trac project and the progress that is making. We hope there can be
mutual collaboration and a shared journey. This approach gives us both the
freedom to continue with our own strategies while allowing us all to stay
engaged with each other and to achieve what I'm sure all of us desire - To
make Trac the best defect tracker on the planet.

At this stage I just wanted to let everyone know we're planning to publish
our proposal to the Apache Incubator later today and invite any questions
or other feedback.


[1 ]http://www.wandisco.com
[2 ]http://www.ubersvn.com
[*] http://www.wandisco.com/careers/open-source-software-developer

Best WIshes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-02 12:41:32 UTC
Permalink
Apologies for messing up the subject on my previous post. I forgot Google
Groups doesn't add the [list name] automatically. Shall we try again!

...
Hi All,

As some of you may already be aware, earlier this year WANdisco[1]
approached members of the Trac development community with a view to working
out how we could most effectively invest development time into the project.
We plan to use Trac as a basis for a defect tracker supplied with our
uberSVN product[2]. Our goal being to develop a tool which can compete
out-of-the-box with other non-opensource defect trackers that have gained
popularity in recent years.

The resulting discussions were interesting and culminated in the idea that
we might get the most done in the shortest time by performing a 'friendly
fork' of Trac and running that as a separate FOSS project. It was felt this
would present the least risk for everyone involved while still leaving
options open for future collaboration. Furthermore, having seen the success
that joining the Apache Software Foundation brought to Subversion, we felt
that this model could reap many benefits for the community of Trac
developers and users and wanted to explore that further.

Since then we've been looking to bring together a team who could drive
these efforts and I'm pleased to say that in the last couple of weeks that
has finally been realised. Not only do we now have a full time lead
developer working out of our Sheffield (UK) office, with support from a
number of colleagues who will contribute significant amounts of time and
energy to this work, we are also recruiting additional freelance developers
to work on this project as independent committers*.

We have a strong and passionate team who will do all they can to make this
a success. However we can't form an entire opensource project on our own.
Our first goal is to enable a community to come together which has
the strength and depth to take this forwards. While the Apache move is an
important part of that, no less important is support from the general Trac
community and especially the current and past committers who have done so
much to get the software to where it is today.

I want to be clear that our intention is in no way to undermine the current
Trac project and the progress that is making. We hope there can be
mutual collaboration and a shared journey. This approach gives us both the
freedom to continue with our own strategies while allowing us all to stay
engaged with each other and to achieve what I'm sure all of us desire - To
make Trac the best defect tracker on the planet.

At this stage I just wanted to let everyone know we're planning to publish
our proposal to the Apache Incubator later today and invite any questions
or other feedback.


[1 ]http://www.wandisco.com
[2 ]http://www.ubersvn.com
[*] http://www.wandisco.com/careers/open-source-software-developer

Best WIshes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-02 16:04:36 UTC
Permalink
On Fri, Dec 2, 2011 at 12:41 PM, Ian Wild <***@wandisco.com> wrote:

> As some of you may already be aware, earlier this year WANdisco[1]
> approached members of the Trac development community with a view to working
> out how we could most effectively invest development time into the project.
> We plan to use Trac as a basis for a defect tracker supplied with our
> uberSVN product[2]. Our goal being to develop a tool which can compete
> out-of-the-box with other non-opensource defect trackers that have gained
> popularity in recent years.
>

...

By way of follow-up, the proposal has now been submitted to the ASF
Incubator.

The Apache Incubator mailing list is public so feel free to follow there if
you're interested in how this goes. The proposal itself is available in the
Apache Wiki at http://wiki.apache.org/incubator/BloodhoundProposal

Ian
--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Simon Cross
2011-12-02 23:36:29 UTC
Permalink
On Fri, Dec 2, 2011 at 6:04 PM, Ian Wild <***@wandisco.com> wrote:
> By way of follow-up, the proposal has now been submitted to the ASF
> Incubator.

I read through the incubator proposal and realized that this proposal
is actually much wider than Trac itself and really extends to include
other parts of the Trac ecosystem. As the de-facto Genshi maintainer
(recently self appointed :) and a Bitten developer, I have a couple of
questions:

* Is Bitten one of the plugins you're planning to include in Bloodhound?
* Do you envisage Bloodhound also forking Genshi?

As Genshi maintainer I'm more than happy to accept contributions from
other developers and I'm in the process of cutting a new Genshi
release (although I encountered a few procedural hiccups like needing
access to some Edgewall servers to upload releases).

Personally I'm happy to see people taking a serious interest in
maintaining and developing Trac and friends -- they're all still quite
cool projects and they good do with a little TLC.

Schiavo
Simon

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-05 14:56:09 UTC
Permalink
Hi Simon,

On Fri, Dec 2, 2011 at 11:36 PM, Simon Cross <***@gmail.com> wrote:
>
> * Is Bitten one of the plugins you're planning to include in Bloodhound?
> * Do you envisage Bloodhound also forking Genshi?


At this point we're still in a period of community building and performing
enough discovery to form a detailed plan. As such precise decisions about
what will be in the first Bloodhound release are yet to be made. There are
a number of plugin authors we'd really like to talk to about inclusion and
we will be making that contact in the next few weeks. We'd rather only fork
what we have to and one of the goals will be to maintain as much
compatibility as we can, so I can't answer the Genshi question just yet.


> Personally I'm happy to see people taking a serious interest in
> maintaining and developing Trac and friends -- they're all still quite
> cool projects and they good do with a little TLC.


That's great. We've been encouraged by the initial feedback and are
certainly serious about making this work. I look forward to updating you
all on progress once a little more water has flowed under the bridge.

Best Wishes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org




>
> As Genshi maintainer I'm more than happy to accept contributions from
> other developers and I'm in the process of cutting a new Genshi
> release (although I encountered a few procedural hiccups like needing
> access to some Edgewall servers to upload releases).
>
>
>
> Schiavo
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+***@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Simon Cross
2011-12-05 15:09:21 UTC
Permalink
On Mon, Dec 5, 2011 at 4:56 PM, Ian Wild <***@wandisco.com> wrote:
> That's great. We've been encouraged by the initial feedback and are
> certainly serious about making this work. I look forward to updating you all
> on progress once a little more water has flowed under the bridge.

Cool. Looking forward to seeing the detailed plan.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ed - 0x1b, Inc.
2011-12-05 16:20:36 UTC
Permalink
On Mon, Dec 5, 2011 at 8:09 AM, Simon Cross <***@gmail.com> wrote:
> On Mon, Dec 5, 2011 at 4:56 PM, Ian Wild <***@wandisco.com> wrote:
>> That's great. We've been encouraged by the initial feedback and are
>> certainly serious about making this work. I look forward to updating you all
>> on progress once a little more water has flowed under the bridge.
>
> Cool. Looking forward to seeing the detailed plan.

yup - what he said +1

I am interested in seeing/helping Trac become fully semantic web enabled.

Ed

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Grzegorz Sobanski
2011-12-08 13:11:41 UTC
Permalink
* Ian Wild <***@wandisco.com> [2011-12-02 13:42]:
> We plan to use Trac as a basis for a defect tracker supplied with our
> uberSVN product[2]. Our goal being to develop a tool which can compete
> out-of-the-box with other non-opensource defect trackers that have gained
> popularity in recent years.
[cut]

Aside from all the "community" issues described in proposal, I'm interested
in technical matters. Do you have a list of things you would like to change in
Bloodhound versus current Trac?
Do you only want to touch distribution and packaging, or also
functionality?

best regards
silk

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-08 17:01:35 UTC
Permalink
On Thu, Dec 8, 2011 at 1:11 PM, Grzegorz Sobanski <***@boktor.net> wrote:

> Aside from all the "community" issues described in proposal, I'm interested
> in technical matters. Do you have a list of things you would like to
> change in
> Bloodhound versus current Trac?
>

Hi Silk,

During the last year we collected a list of improvements that we (and
others we've spoken to) believe would make Trac better. Of course there's
isn't much new there compared to the existing Trac wishlist / roadmap. Our
view was always that we wanted to put time into building out some of these
things (Multiproject support springs to mind for example).


> Do you only want to touch distribution and packaging, or also
> functionality?
>

Both. The packaging is important - installation experience and first
impressions really count. I'm not saying the minimalist approach Trac takes
is wrong, but it doesn't suit a busy person choosing a defect tracker and
wanting to quickly evaluate and compare features, usability, functionality
etc.

So there will be effort spent on packaging, look and feel, and generally
supplying a more complete product out of the box. There is plenty of
functionality that we hope can be added within Bloodhound, some supplied by
existing plugins whose authors we'd hope to work with and some needing to
be written from scratch. Of course we're still in the planning period and
nothing has been locked down regarding specific deliverables or a roadmap.
I'd re-iterate that while WANdisco is leading this effort we don't plan to
dictate the roadmap. It's a community project and these decisions will be
made within an open group.

Best Wishes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.


http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Olemis Lang
2011-12-08 17:14:17 UTC
Permalink
Hi everybody !
:)

On Thu, Dec 8, 2011 at 12:01 PM, Ian Wild <***@wandisco.com> wrote:
>
> On Thu, Dec 8, 2011 at 1:11 PM, Grzegorz Sobanski <***@boktor.net> wrote:
>>
>> Aside from all the "community" issues described in proposal, I'm interested
>> in technical matters. Do you have a list of things you would like to change in
>> Bloodhound versus current Trac?
>
>
> Hi Silk,
>
> During the last year we collected a list of improvements that we (and others we've spoken to) believe would make Trac better. Of course there's isn't much new there compared to the existing Trac wishlist / roadmap. Our view was always that we wanted to put time into building out some of these things (Multiproject support springs to mind for example).
>
>>
>> Do you only want to touch distribution and packaging, or also
>> functionality?
>
>
> Both. The packaging is important - installation experience and first impressions really count. I'm not saying the minimalist approach Trac takes is wrong, but it doesn't suit a busy person choosing a defect tracker and wanting to quickly evaluate and compare features, usability, functionality etc.
>
[...]

... one question in the case of current Trac plugins , how will it
work the workflow involved in developing / adapting them ? Will they
still be developed in trac-hacks ... will the code be migrated onto
Bloodhound repository (separate from core components ... or not ) ? or
a separate extensions repository ? Or will it be a big-scale scenery
of what happens today with TracMercurial plugin inside Trac main SVN
repos ... AFAICS ?

PS: Thnx for your initiative and for supporting this effort .

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw

Featured article : Personalizando imagenes mostradas al compartir
páginas en sitios sociales
Get a signature like this. CLICK HERE.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-12 16:42:42 UTC
Permalink
On Thu, Dec 8, 2011 at 5:14 PM, Olemis Lang <***@gmail.com> wrote:

>
> ... one question in the case of current Trac plugins , how will it
> work the workflow involved in developing / adapting them ? Will they
> still be developed in trac-hacks ... will the code be migrated onto
> Bloodhound repository (separate from core components ... or not ) ? or
> a separate extensions repository ? Or will it be a big-scale scenery
> of what happens today with TracMercurial plugin inside Trac main SVN
> repos ... AFAICS ?
>
>
Hi Olemis,

There will need to be something of case by case approach to this. We'll be
working closely with some of the plugin developers and where it makes sense
and is possible we would like to re-license plugins to become a core part
of the Bloodhound distribution. We also plan to be to work with Trac-hacks
guys to develop some of the popular plugins there and there have been some
really interesting ideas about how we could help that site develop.


> PS: Thnx for your initiative and for supporting this effort .
>

The more discussions I have with people about this approach, the more
comfortable I get that this is the right one for everyone involved. There
is undoubtedly a lot of pent up demand for an Open Source defect tracker
that Trac can meet, but doesn't out of the box. If we can take the elegance
of the Trac architecture and combine it with a functional, attractive and
well designed distribution then I'm confident this will have a big impact
for users.

Best Wishes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
osimons
2011-12-25 03:14:41 UTC
Permalink
On Dec 2, 1:41 pm, Ian Wild <***@wandisco.com> wrote:
> Apologies for messing up the subject on my previous post. I forgot Google
> Groups doesn't add the [list name] automatically. Shall we try again!
>
> ...
> Hi All,
>
> As some of you may already be aware, earlier this year WANdisco[1]
> approached members of the Trac development community with a view to working
> out how we could most effectively invest development time into the project.
> We plan to use Trac as a basis for a defect tracker supplied with our
> uberSVN product[2]. Our goal being to develop a tool which can compete
> out-of-the-box with other non-opensource defect trackers that have gained
> popularity in recent years.
>
> The resulting discussions were interesting and culminated in the idea that
> we might get the most done in the shortest time by performing a 'friendly
> fork' of Trac and running that as a separate FOSS project. It was felt this
> would present the least risk for everyone involved while still leaving
> options open for future collaboration. Furthermore, having seen the success
> that joining the Apache Software Foundation brought to Subversion, we felt
> that this model could reap many benefits for the community of Trac
> developers and users and wanted to explore that further.
>
> Since then we've been looking to bring together a team who could drive
> these efforts and I'm pleased to say that in the last couple of weeks that
> has finally been realised. Not only do we now have a full time lead
> developer working out of our Sheffield (UK) office, with support from a
> number of colleagues who will contribute significant amounts of time and
> energy to this work, we are also recruiting additional freelance developers
> to work on this project as independent committers*.
>
> We have a strong and passionate team who will do all they can to make this
> a success. However we can't form an entire opensource project on our own.
> Our first goal is to enable a community to come together which has
> the strength and depth to take this forwards. While the Apache move is an
> important part of that, no less important is support from the general Trac
> community and especially the current and past committers who have done so
> much to get the software to where it is today.
>
> I want to be clear that our intention is in no way to undermine the current
> Trac project and the progress that is making. We hope there can be
> mutual collaboration and a shared journey. This approach gives us both the
> freedom to continue with our own strategies while allowing us all to stay
> engaged with each other and to achieve what I'm sure all of us desire - To
> make Trac the best defect tracker on the planet.
>
> At this stage I just wanted to let everyone know we're planning to publish
> our proposal to the Apache Incubator later today and invite any questions
> or other feedback.
>
> [1 ]http://www.wandisco.com
> [2 ]http://www.ubersvn.com
> [*]http://www.wandisco.com/careers/open-source-software-developer
>
> Best WIshes,
>
> Ian
>
> --
> Ian Wild
> Director of Engineering
> WANdisco, Inc.
>
> http://www.wandisco.com
>
> uberSVN: Apache Subversion Made Easyhttp://www.uberSVN.com<http://www.ubersvn.com/>
>
> Everything you need to deploy Subversion in the Enterprisehttp://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>
>
> Subversion communityhttp://www.svnforum.org


Hi Trac & (future) Bloodhound communities.

I have previously shared my thoughts in bits & pieces in various
communication with interested parties, but for the sake of openness
and clarity for all I figured a public summary would be in order.

First of all, Trac is BSD licensed open source software. Everyone is
free to use it and reuse it as they please - do anything except blame
us for any problems. Forks have happened before, and forks will no
doubt happen again. In that perspective the Bloodhound proposal is a
natural process.

As many of you know, I have sort of rolled my own distribution of Trac
too as the foundation for our hosted service. However, I've made my
modifications in custom plugins - adding to, changing, or removing
features via code and configuration. I've also contributed various
plugins and try to be involved in all the code that I actually use;
+95% of which is public. The version of Trac that I actually use is
pulled straight from the Edgewall repository, and I make no patches to
the Trac code. My decision all those years ago was to work with the
Trac project to improve it wherever time and ability allowed.

Bloodhound represents much the exact opposite of this, and it makes me
uncertain. It is uncertainty that may be unfounded once the project
gets going and we can see the actual plans, project activity and
interactivity between the project members. Then again it may not. I
won't be passing any judgement on the project for quite some time yet,
and from the outset my standpoint have been that if Bloodhound can
build a 'better Trac' I will not hesitate to use it.

I do find it strange that a fork is necessary before any work can
commence. I find it strange that none of the suggested Bloodhound team
have much association with Trac or plugins - I find some scattered
occurrences in mailing lists and tickets, but really not much code and
patches that I can find. However, good people can naturally make magic
happen regardless of what guidance history provides. I am sure they
can pull their weight and hit whatever goals the Bloodhound project
sets.

Which brings me back to actually describing the uncertainty I feel: A
full team of people going full speed ahead to achieve whatever goals
they set themselves in their new-founded community. As the proposal
also say, there will be a learning curve for them - learning Trac,
learning Trac development, and being educated in matters ranging for
compatibility, to i18n/l10n, existing plugins and various bits of
history that explain the rationale for decisions made (or not made)
because they were bad ideas (at least at the time). Growing that
knowledge in a community takes a lot of effort.

I will actually need to consider how I want to spend my own project
time. One part of me say very firmly that even though Bloodhound forks
the project, the decision to actually fork any code in non-compatible
ways should not be taken lightly. But if I spend my time supporting
the Bloodhound project and its developers via #trac IRC channel, open
mailing mailing lists, and tickets; what then becomes of my available
time for Trac project and plugins? I don't know. The other side of me
says to just let Bloodhound carry on as they please, and focus on what
matters to me now.

The wait-and-see approach can leave the Trac project standing and the
Bloodhound project standing, or perhaps one project succeed over time.
Or, the distinct possibility that neither project survives as already
thin resources are spread out across too many dimensions. Will the
users bother to keep on top of both projects? Will I as Trac and
plugin developer spend my time discussing what goes on at the
Bloodhound project whether I like to or not? When users start
reporting Bloodhound-related plugin bugs, that surely is a very
distinct possibility.

It is a shame that the project forks just because Apache Software
Foundation affinity is a hard requirement. I've seen all kinds of
discussions about forks in various projects over the years, but
forking the project without expressed commitment (or interest) from
any current core or plugin developer is something I can not remember
seeing before - at least not without a clear sense of direction. The
expected behavior would be to throw the handful of developers into the
existing project, and then fork if for some reason that does not work
out. All code would stay BSD, and according to proposal the project
could fork at any time and no one would be worse off. I just don't
understand why applying the effort outside the Apache umbrella would
have any less value to the corporate sponsors of the Bloodhound
project? The man-month applied on a feature branch now would be just
as valuable regardless of which public repository it was applied to,
would it not?

The Trac code (and most plugin code) is very free open source. From my
perpective there are no hard feelings about that at all. It is the
nature of the work we do and the licenses we work with. But, I could
still wish that the process and priorities had been different at the
forking end - or at least be made public in manner that is clear for
all to see.

My self-appointed role in the Trac project is being "champion" for the
needs of a stable, compatible, loosely-coupled system - a small core
that largely lives to support the plugin community and where everyone
if free to offer 'community distributions' that pick whatever parts
they need. My role thrive on activity by others so there are things
for me to evaluate, coordinate, guide, and adjust. It is a distinct
possibility that I will be sucked backwards into the Bloodhound -
primarily because 20 years of industry software project experience
(yes I'm that old) have really confirmed that I cannot keep my mouth
shut if I have an opinion to offer...

I would however like to hear more of the opinion of other Trac and
plugin developers about how you all envision supporting this
fragmented project structure. Are you prepared to switch your own
usage to the new project, and perhaps switch the main development of
your own plugins to a Bloodhound as a new base - or at least test
against it and provide the necessary compat abstraction if needed
across different versions in different projects? Or, put differently;
what is the level of success needed by Bloodhound before you are
prepared to make the effort - or even fully switch? One of the
expressed goals is to provide a "TicketSystem2" as 'the best defect
tracker on the planet'. Which is fine, but for that to happen pretty
much every Ticket-related plugin at Trac-Hacks.org will likely break -
it will need to be fixed, integrated, or forked. Have you all
considered what supporting 2 communities may involve?

The intention of this email was to describe my thoughts and
uncertainty. Currently I have a hard time believing that two vibrant
divergent communities can survive. In the end I think there can be
only one, but from 'now' until 'then' there will be much work to be
done. The decision I have to make is if I should walk into the
Bloodhound project facing forward, or decide to just ignore it and
look after my own things. But looking after my own things would to
some extent be a small dagger in the back of both projects making
either less likely to succeed. I don't consider myself a great
developer by any standards, but I know what I like and I know that
what I do makes a difference.

I positively hate the idea of providing feedback to a proposal that
have so little essence. I think Bloodhound project stated goals and
plans are wafer-thin from a software development standpoint. And,
judging from the Apache general incubator mailing list so far in
December there may be nothing more forthcoming for quite some time
either seeing plans would be for the new Bloodhound developer
community to decide. Whoever they may be, and whoever from us decide
to get involved. Which really brings the problem full circle.

I really wish the efforts were joined at the hip for now, and I'd have
no reason to feel uncertain about a fork if there were months of
preceding argument about project direction here at trac-dev. I would
be blatantly obvious that a fork was needed, costing what it may.
However, it is my firm belief that a software fork born out of
critical discussion between people that disagree, will be of much
better quality than a fork largely built by consensus in the offices
of a corporate sponsor.

People? Thoughts?



:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Steffen Hoffmann
2011-12-25 15:32:17 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 25.12.2011 04:14, schrieb osimons:
> Hi Trac & (future) Bloodhound communities.
>
> I have previously shared my thoughts in bits & pieces in various
> communication with interested parties, but for the sake of openness
> and clarity for all I figured a public summary would be in order.
>
> ...
>
> People? Thoughts?

Thanks for asking.

My roughly 3 years of slow progress towards becoming a member of the
Trac community won't let me speak as authoritative as you, Simon. And I
didn't follow Apache general incubator mailing list at all. Anyway, I've
read all announcements about the upcoming Bloodhound fork here very
carefully and I confess that I'm sharing a lot of the uneasy feelings
with you.

I learned that Trac has a really small developer base these days. So
small, that it hurts me at several occasions, because noble ideas simple
can't be approached for the lack of time and maybe other resources too.
OTOH, two new developers have been invited and joined the core team this
year. And while obviously not involved with many fancy new features, as
often as I looked into recent commit history I've seen all of them doing
rather ambitious work behind the scenes. Better API documentation,
continued db backend re-factoring, progress towards more i18n support
for wiki content and many small fixes and enhancements come to my mind
instantly.

Certainty, there are a bunch of alternative wikis, repository browsers
and bug trackers out there. In my eyes Trac is still unique for it's
consequent "reduce-to-the-max" core design and rather rigid policy of
using plugins for may tasks, that are considered part of core elsewhere,
and renown for it's plugin support too.

When facing the growing Trac functionality and the current amount of
plugins at trac-hacks.org and elsewhere, the call for better overview,
easier plugin selection (get best plugin for given task) and convenient
feature-enriched packages for better 1st-time user experience is only
consequent. As a Debian user I'd solve this by better support for
distributors. Btw, I already established contact to the Debian Python
apps packaging team myself, this has been very welcome, but I had no
time to contribute there by now.

I fear that my English isn't good enough to point out critical issues
with the Bloodhound proposal. I'm with Osimons for the most of his
gentle rambling against the massive effort for just the fork, and that
the true shape of the new project seem still very blurred and unclear.

There is a saying: 'You know me by my actions, not by my words'. Among
other things it had been announced by Wandisco representatives, that
current (trac-hacks) developers and plugin maintainers would be
contacted to speak about possible ways of collaboration. While I felt
like this would qualify me at least for AccountManagerPlugin and
TagsPlugin, I've heard nothing by now.

Not that I'd need that special attention. I don't complain at all. In
fact I would be a bit lost for words in the current situation. What
should I expect? What will be expected from the other side? I could
never compete to professionals doing it full-time as their daily
business. As a non-professional in the software development business I
can only dedicate a small part of my private life to work on Trac and
plugins, mostly late evenings, after children went to bed.

Inside the Trac community this has never been a problem so far. Even
with initially very few coding experience I've found patient listeners
and professional advice on my requests here at the mailing list as well
as at #trac IRC channel. When I had a serious Trac problem and was in
doubt, if I could approach that or better give up, Simons hints and
encouraging words confirmed me to stay and try. Just one occasion that
I'll never forget.

I'm thankful indeed and eager to give something back. My current plugin
maintainer status and loose affiliation with Trac core will continue, at
least until it is clear that Bloodhound will become the new Trac. But
this won't happen easily. Most announcements suggest effort that could
and maybe better should be done inside Trac and trac-hacks for more
livid development, and better packaging support by/with existing
operation system distributors on the other side.

If you don't see my point here, just one more thought: Today
professional, key-turn application roll-outs are often virtual machines
in cluster setups. How could we encourage wider Trac adoption more
economic and sustainable within tight resource constraints, if not by
working closely with OS vendors? I don't see, that anyone here goes into
building images for VMware, VirtualBox, Xen & Co.

I heartily welcome new developers joining here. Familiarize with the
Trac ecosystem, become a part of it. You'll be respected and encouraged
to take responsibility according to quantity and quality of
contributions as I witnessed several times by now. Having sponsors to
donate paid developer time could even yield a leap-frog progress at some
issues.

OTOH a diversion won't be good for any of the involved parties. Trac
(plugin) developer base could be finally drained below the critical mass
to do both, maintain existing solutions and produce remarkable, valuable
new stuff. Just for getting the fame of Trac and respect of the
community for this project into the Apache domain? I hope this isn't the
hidden meaning of the Bloodhound proposal, and most probably it won't
work out in the end anyway.

Would love to hear more people to speak-up here too.

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

iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL
j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg
=HhL5
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ethan Jucovy
2011-12-25 15:55:32 UTC
Permalink
Thank you, Simon and Steffan -- +1 to everything you have both said. I am
a deeply committed Trac user (since 2006), occasional plugin author and
casual observer of the core codebase and development process and I share
your concerns about the Bloodhound effort. In my experience Trac's design
and architecture make plugin development very easy, and I am not sure what
value there is in a pre-emptive fork that does not first attempt to work
within the existing core architecture and community processes.

Of course I understand that a corporate effort will generally need to
commit upfront to getting its own goals accomplished as a higher priority
than working with upstream constraints. But to reframe that reasonable
internal prioritization as an open source fork under the Apache name seems
detrimental to everybody, as Simon and Steffan have said.

Again repeating what others have said .. the Trac community could certainly
use more and better integrator-level documentation, configurations and
"known good sets" of curated plugins, explicitly managed outside the Trac
core development process. But there is no reason per se why this should
not happen at a symbiotic layer sitting on top of the Trac core -- not a
pre-emptive fork.

To answer Simon's question, I plan to monitor Bloodhound development, but I
do not expect to switch to using it or developing against it. The Trac
code and community have consistently impressed me as a good, reliable,
streamlined base that I can configure to do pretty much whatever I need.
The very action of announcing an intent to fork, rather than working in
and atop Trac's well-designed and long-established component architecture
system and plugin community, makes me think that the Bloodhound project is
likely to bake in a more opinionated, less robust and less configurable
core.

On Sun, Dec 25, 2011 at 10:32 AM, Steffen Hoffmann <***@web.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 25.12.2011 04:14, schrieb osimons:
> > Hi Trac & (future) Bloodhound communities.
> >
> > I have previously shared my thoughts in bits & pieces in various
> > communication with interested parties, but for the sake of openness
> > and clarity for all I figured a public summary would be in order.
> >
> > ...
> >
> > People? Thoughts?
>
> Thanks for asking.
>
> My roughly 3 years of slow progress towards becoming a member of the
> Trac community won't let me speak as authoritative as you, Simon. And I
> didn't follow Apache general incubator mailing list at all. Anyway, I've
> read all announcements about the upcoming Bloodhound fork here very
> carefully and I confess that I'm sharing a lot of the uneasy feelings
> with you.
>
> I learned that Trac has a really small developer base these days. So
> small, that it hurts me at several occasions, because noble ideas simple
> can't be approached for the lack of time and maybe other resources too.
> OTOH, two new developers have been invited and joined the core team this
> year. And while obviously not involved with many fancy new features, as
> often as I looked into recent commit history I've seen all of them doing
> rather ambitious work behind the scenes. Better API documentation,
> continued db backend re-factoring, progress towards more i18n support
> for wiki content and many small fixes and enhancements come to my mind
> instantly.
>
> Certainty, there are a bunch of alternative wikis, repository browsers
> and bug trackers out there. In my eyes Trac is still unique for it's
> consequent "reduce-to-the-max" core design and rather rigid policy of
> using plugins for may tasks, that are considered part of core elsewhere,
> and renown for it's plugin support too.
>
> When facing the growing Trac functionality and the current amount of
> plugins at trac-hacks.org and elsewhere, the call for better overview,
> easier plugin selection (get best plugin for given task) and convenient
> feature-enriched packages for better 1st-time user experience is only
> consequent. As a Debian user I'd solve this by better support for
> distributors. Btw, I already established contact to the Debian Python
> apps packaging team myself, this has been very welcome, but I had no
> time to contribute there by now.
>
> I fear that my English isn't good enough to point out critical issues
> with the Bloodhound proposal. I'm with Osimons for the most of his
> gentle rambling against the massive effort for just the fork, and that
> the true shape of the new project seem still very blurred and unclear.
>
> There is a saying: 'You know me by my actions, not by my words'. Among
> other things it had been announced by Wandisco representatives, that
> current (trac-hacks) developers and plugin maintainers would be
> contacted to speak about possible ways of collaboration. While I felt
> like this would qualify me at least for AccountManagerPlugin and
> TagsPlugin, I've heard nothing by now.
>
> Not that I'd need that special attention. I don't complain at all. In
> fact I would be a bit lost for words in the current situation. What
> should I expect? What will be expected from the other side? I could
> never compete to professionals doing it full-time as their daily
> business. As a non-professional in the software development business I
> can only dedicate a small part of my private life to work on Trac and
> plugins, mostly late evenings, after children went to bed.
>
> Inside the Trac community this has never been a problem so far. Even
> with initially very few coding experience I've found patient listeners
> and professional advice on my requests here at the mailing list as well
> as at #trac IRC channel. When I had a serious Trac problem and was in
> doubt, if I could approach that or better give up, Simons hints and
> encouraging words confirmed me to stay and try. Just one occasion that
> I'll never forget.
>
> I'm thankful indeed and eager to give something back. My current plugin
> maintainer status and loose affiliation with Trac core will continue, at
> least until it is clear that Bloodhound will become the new Trac. But
> this won't happen easily. Most announcements suggest effort that could
> and maybe better should be done inside Trac and trac-hacks for more
> livid development, and better packaging support by/with existing
> operation system distributors on the other side.
>
> If you don't see my point here, just one more thought: Today
> professional, key-turn application roll-outs are often virtual machines
> in cluster setups. How could we encourage wider Trac adoption more
> economic and sustainable within tight resource constraints, if not by
> working closely with OS vendors? I don't see, that anyone here goes into
> building images for VMware, VirtualBox, Xen & Co.
>
> I heartily welcome new developers joining here. Familiarize with the
> Trac ecosystem, become a part of it. You'll be respected and encouraged
> to take responsibility according to quantity and quality of
> contributions as I witnessed several times by now. Having sponsors to
> donate paid developer time could even yield a leap-frog progress at some
> issues.
>
> OTOH a diversion won't be good for any of the involved parties. Trac
> (plugin) developer base could be finally drained below the critical mass
> to do both, maintain existing solutions and produce remarkable, valuable
> new stuff. Just for getting the fame of Trac and respect of the
> community for this project into the Apache domain? I hope this isn't the
> hidden meaning of the Bloodhound proposal, and most probably it won't
> work out in the end anyway.
>
> Would love to hear more people to speak-up here too.
>
> Steffen Hoffmann
> (hasienda)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL
> j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg
> =HhL5
> -----END PGP SIGNATURE-----
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+***@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Greg Troxel
2011-12-25 16:01:06 UTC
Permalink
Ethan Jucovy <***@gmail.com> writes:

> Thank you, Simon and Steffan -- +1 to everything you have both said. I am
> a deeply committed Trac user (since 2006), occasional plugin author and
> casual observer of the core codebase and development process and I share
> your concerns about the Bloodhound effort. In my experience Trac's design
> and architecture make plugin development very easy, and I am not sure what
> value there is in a pre-emptive fork that does not first attempt to work
> within the existing core architecture and community processes.

I've been a user since 2007, contributed only a few fixes to plugins,
but have been reading the list more or less. I also find the fork and
joining-apache notion a bit boggling. I don't mean to say I think ASF
is broken, but the present situation just feels very odd to me.
Rob Guttman
2011-12-25 16:30:34 UTC
Permalink
+1 to this latest thread. This is my third company using Trac and I've contributed a number of plugins over the years: http://trac-hacks.org/wiki/robguttman

Ethan's point about configurability is exactly why I prefer Trac over others. I don't know enough about Bloodhound to comment on specifics. In general, I like the idea of people wanting to contribute more to the Trac community. But if the effort is likely to spread limited resources even thinner, that concerns me. I would rather see more support for Trac as we know it such as bringing trac-hacks.org up-to-date (possibly at a new home if necessary) and making it as supportive for collaboration as github (e.g., through new plugins). That's what I think the community really needs from this humble plugin developer's perspective.

- Rob

PS: Happy holidays!

On Dec 25, 2011, at 10:55 AM, Ethan Jucovy wrote:

> Thank you, Simon and Steffan -- +1 to everything you have both said. I am a deeply committed Trac user (since 2006), occasional plugin author and casual observer of the core codebase and development process and I share your concerns about the Bloodhound effort. In my experience Trac's design and architecture make plugin development very easy, and I am not sure what value there is in a pre-emptive fork that does not first attempt to work within the existing core architecture and community processes.
>
> Of course I understand that a corporate effort will generally need to commit upfront to getting its own goals accomplished as a higher priority than working with upstream constraints. But to reframe that reasonable internal prioritization as an open source fork under the Apache name seems detrimental to everybody, as Simon and Steffan have said.
>
> Again repeating what others have said .. the Trac community could certainly use more and better integrator-level documentation, configurations and "known good sets" of curated plugins, explicitly managed outside the Trac core development process. But there is no reason per se why this should not happen at a symbiotic layer sitting on top of the Trac core -- not a pre-emptive fork.
>
> To answer Simon's question, I plan to monitor Bloodhound development, but I do not expect to switch to using it or developing against it. The Trac code and community have consistently impressed me as a good, reliable, streamlined base that I can configure to do pretty much whatever I need. The very action of announcing an intent to fork, rather than working in and atop Trac's well-designed and long-established component architecture system and plugin community, makes me think that the Bloodhound project is likely to bake in a more opinionated, less robust and less configurable core.
>
> On Sun, Dec 25, 2011 at 10:32 AM, Steffen Hoffmann <***@web.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 25.12.2011 04:14, schrieb osimons:
> > Hi Trac & (future) Bloodhound communities.
> >
> > I have previously shared my thoughts in bits & pieces in various
> > communication with interested parties, but for the sake of openness
> > and clarity for all I figured a public summary would be in order.
> >
> > ...
> >
> > People? Thoughts?
>
> Thanks for asking.
>
> My roughly 3 years of slow progress towards becoming a member of the
> Trac community won't let me speak as authoritative as you, Simon. And I
> didn't follow Apache general incubator mailing list at all. Anyway, I've
> read all announcements about the upcoming Bloodhound fork here very
> carefully and I confess that I'm sharing a lot of the uneasy feelings
> with you.
>
> I learned that Trac has a really small developer base these days. So
> small, that it hurts me at several occasions, because noble ideas simple
> can't be approached for the lack of time and maybe other resources too.
> OTOH, two new developers have been invited and joined the core team this
> year. And while obviously not involved with many fancy new features, as
> often as I looked into recent commit history I've seen all of them doing
> rather ambitious work behind the scenes. Better API documentation,
> continued db backend re-factoring, progress towards more i18n support
> for wiki content and many small fixes and enhancements come to my mind
> instantly.
>
> Certainty, there are a bunch of alternative wikis, repository browsers
> and bug trackers out there. In my eyes Trac is still unique for it's
> consequent "reduce-to-the-max" core design and rather rigid policy of
> using plugins for may tasks, that are considered part of core elsewhere,
> and renown for it's plugin support too.
>
> When facing the growing Trac functionality and the current amount of
> plugins at trac-hacks.org and elsewhere, the call for better overview,
> easier plugin selection (get best plugin for given task) and convenient
> feature-enriched packages for better 1st-time user experience is only
> consequent. As a Debian user I'd solve this by better support for
> distributors. Btw, I already established contact to the Debian Python
> apps packaging team myself, this has been very welcome, but I had no
> time to contribute there by now.
>
> I fear that my English isn't good enough to point out critical issues
> with the Bloodhound proposal. I'm with Osimons for the most of his
> gentle rambling against the massive effort for just the fork, and that
> the true shape of the new project seem still very blurred and unclear.
>
> There is a saying: 'You know me by my actions, not by my words'. Among
> other things it had been announced by Wandisco representatives, that
> current (trac-hacks) developers and plugin maintainers would be
> contacted to speak about possible ways of collaboration. While I felt
> like this would qualify me at least for AccountManagerPlugin and
> TagsPlugin, I've heard nothing by now.
>
> Not that I'd need that special attention. I don't complain at all. In
> fact I would be a bit lost for words in the current situation. What
> should I expect? What will be expected from the other side? I could
> never compete to professionals doing it full-time as their daily
> business. As a non-professional in the software development business I
> can only dedicate a small part of my private life to work on Trac and
> plugins, mostly late evenings, after children went to bed.
>
> Inside the Trac community this has never been a problem so far. Even
> with initially very few coding experience I've found patient listeners
> and professional advice on my requests here at the mailing list as well
> as at #trac IRC channel. When I had a serious Trac problem and was in
> doubt, if I could approach that or better give up, Simons hints and
> encouraging words confirmed me to stay and try. Just one occasion that
> I'll never forget.
>
> I'm thankful indeed and eager to give something back. My current plugin
> maintainer status and loose affiliation with Trac core will continue, at
> least until it is clear that Bloodhound will become the new Trac. But
> this won't happen easily. Most announcements suggest effort that could
> and maybe better should be done inside Trac and trac-hacks for more
> livid development, and better packaging support by/with existing
> operation system distributors on the other side.
>
> If you don't see my point here, just one more thought: Today
> professional, key-turn application roll-outs are often virtual machines
> in cluster setups. How could we encourage wider Trac adoption more
> economic and sustainable within tight resource constraints, if not by
> working closely with OS vendors? I don't see, that anyone here goes into
> building images for VMware, VirtualBox, Xen & Co.
>
> I heartily welcome new developers joining here. Familiarize with the
> Trac ecosystem, become a part of it. You'll be respected and encouraged
> to take responsibility according to quantity and quality of
> contributions as I witnessed several times by now. Having sponsors to
> donate paid developer time could even yield a leap-frog progress at some
> issues.
>
> OTOH a diversion won't be good for any of the involved parties. Trac
> (plugin) developer base could be finally drained below the critical mass
> to do both, maintain existing solutions and produce remarkable, valuable
> new stuff. Just for getting the fame of Trac and respect of the
> community for this project into the Apache domain? I hope this isn't the
> hidden meaning of the Bloodhound proposal, and most probably it won't
> work out in the end anyway.
>
> Would love to hear more people to speak-up here too.
>
> Steffen Hoffmann
> (hasienda)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL
> j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg
> =HhL5
> -----END PGP SIGNATURE-----
>
> --
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-25 20:45:30 UTC
Permalink
Seasons greetings to all,

I'm very pleased to see a discussion starting on this. I was hoping for an
ongoing open dialogue and co-operation between the Trac and Apache
Bloodhound efforts and would encourage as many people as possible to get
involved in this dialogue. I'm concerned that anyone here regards Apache
Bloodhound as a threat to Trac. Whether this ultimately develops as
a 'friendly fork', derivative or something else, managed properly both
approaches can succeed and give to each other without jeopardising
the viability of either.

There may be questions that it is too early to answer, however I can
address a few of the previous points now. WANdisco spent the last year
investigating how we could most effectively participate and make a large
investment in the development of an open source defect tracker to
equal equivalent commercially available tools. In many software categories
there are open source tools that take on and often hands down beat
commercial options, but that's not true for any open source defect tracker
today. Our view was that Trac represents the best vehicle to achieve that
and working within the existing infrastructure was discussed at some
length.

The Trac ethos is a fine one, which can be equated to an advanced assembly
kit that people must put together in just the way they want before they can
effectively use it. There are companies that offer pre-configured versions
of Trac and professional services around it, but there is nothing that an
average tools manager or evaluator can quickly test, use and deploy as part
of an accessible open source package. That's not all there is to the Apache
Bloodhound proposal, but it's important to highlight that there is a
difference in approach and goal there. I personally don't believe either
approach is wrong, just different.

The benefits that an open source foundation can bring to any project are
well documented. As well as gaining an existing development and tools
eco-system, the strong governance and very important legal protections that
the Apache Software Foundation provide are not matched by the current Trac
setup. As a business investing heavily in an open source project we are
duty bound to ensure certain things about our investment. The impression we
got from the existing 'core' of the Trac group was that they wouldn't be in
a position to put those things in place and it was they who suggested that
the best way forwards was a friendly fork.

So now WANdisco is gathering a strong team who will work on this as part of
a wider Apache based community. It isn't anyone's intention to detract from
ongoing Trac development in anyway and I don't believe Apache Bloodhound
will. As part of Apache there will be a community who would hope to take
the best things from Trac, and I'm sure work to address the other points
like Trac-hacks and the plugin eco-system among others. In no circumstances
will we want to do that in a way which would undermines Trac though and I'd
hope that all of these areas can be discussed and agreed upon as they are
being approached.

It's still early days and there is a lot of work to do. Within Apache the
discussion will be open and available to anyone who wants to get involved.
I don't think anyone should feel under pressure to do that, but you're more
than welcome. I'd also be happy to facilitate ongoing discussions, maybe
even calls and video conferences between us all to ensure that we aren't
conflicting and ultimately that we're providing the best possible software
for users.

Best Wishes,

Ian
--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion

Subversion community
http://www.svnforum.org



On Sun, Dec 25, 2011 at 4:30 PM, Rob Guttman <***@gmail.com> wrote:
>
> +1 to this latest thread. This is my third company using Trac and I've
contributed a number of plugins over the years:
http://trac-hacks.org/wiki/robguttman
> Ethan's point about configurability is exactly why I prefer Trac over
others. I don't know enough about Bloodhound to comment on specifics. In
general, I like the idea of people wanting to contribute more to the Trac
community. But if the effort is likely to spread limited resources even
thinner, that concerns me. I would rather see more support for Trac as we
know it such as bringing trac-hacks.org up-to-date (possibly at a new home
if necessary) and making it as supportive for collaboration as github
(e.g., through new plugins). That's what I think the community really
needs from this humble plugin developer's perspective.
> - Rob
> PS: Happy holidays!
> On Dec 25, 2011, at 10:55 AM, Ethan Jucovy wrote:
>
> Thank you, Simon and Steffan -- +1 to everything you have both said. I
am a deeply committed Trac user (since 2006), occasional plugin author and
casual observer of the core codebase and development process and I share
your concerns about the Bloodhound effort. In my experience Trac's design
and architecture make plugin development very easy, and I am not sure what
value there is in a pre-emptive fork that does not first attempt to work
within the existing core architecture and community processes.
> Of course I understand that a corporate effort will generally need to
commit upfront to getting its own goals accomplished as a higher priority
than working with upstream constraints. But to reframe that reasonable
internal prioritization as an open source fork under the Apache name seems
detrimental to everybody, as Simon and Steffan have said.
> Again repeating what others have said .. the Trac community could
certainly use more and better integrator-level documentation,
configurations and "known good sets" of curated plugins, explicitly managed
outside the Trac core development process. But there is no reason per se
why this should not happen at a symbiotic layer sitting on top of the Trac
core -- not a pre-emptive fork.
> To answer Simon's question, I plan to monitor Bloodhound development, but
I do not expect to switch to using it or developing against it. The Trac
code and community have consistently impressed me as a good, reliable,
streamlined base that I can configure to do pretty much whatever I need.
The very action of announcing an intent to fork, rather than working in
and atop Trac's well-designed and long-established component architecture
system and plugin community, makes me think that the Bloodhound project is
likely to bake in a more opinionated, less robust and less configurable
core.
>
> On Sun, Dec 25, 2011 at 10:32 AM, Steffen Hoffmann <***@web.de> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 25.12.2011 04:14, schrieb osimons:
>> > Hi Trac & (future) Bloodhound communities.
>> >
>> > I have previously shared my thoughts in bits & pieces in various
>> > communication with interested parties, but for the sake of openness
>> > and clarity for all I figured a public summary would be in order.
>> >
>> > ...
>> >
>> > People? Thoughts?
>>
>> Thanks for asking.
>>
>> My roughly 3 years of slow progress towards becoming a member of the
>> Trac community won't let me speak as authoritative as you, Simon. And I
>> didn't follow Apache general incubator mailing list at all. Anyway, I've
>> read all announcements about the upcoming Bloodhound fork here very
>> carefully and I confess that I'm sharing a lot of the uneasy feelings
>> with you.
>>
>> I learned that Trac has a really small developer base these days. So
>> small, that it hurts me at several occasions, because noble ideas simple
>> can't be approached for the lack of time and maybe other resources too.
>> OTOH, two new developers have been invited and joined the core team this
>> year. And while obviously not involved with many fancy new features, as
>> often as I looked into recent commit history I've seen all of them doing
>> rather ambitious work behind the scenes. Better API documentation,
>> continued db backend re-factoring, progress towards more i18n support
>> for wiki content and many small fixes and enhancements come to my mind
>> instantly.
>>
>> Certainty, there are a bunch of alternative wikis, repository browsers
>> and bug trackers out there. In my eyes Trac is still unique for it's
>> consequent "reduce-to-the-max" core design and rather rigid policy of
>> using plugins for may tasks, that are considered part of core elsewhere,
>> and renown for it's plugin support too.
>>
>> When facing the growing Trac functionality and the current amount of
>> plugins at trac-hacks.org and elsewhere, the call for better overview,
>> easier plugin selection (get best plugin for given task) and convenient
>> feature-enriched packages for better 1st-time user experience is only
>> consequent. As a Debian user I'd solve this by better support for
>> distributors. Btw, I already established contact to the Debian Python
>> apps packaging team myself, this has been very welcome, but I had no
>> time to contribute there by now.
>>
>> I fear that my English isn't good enough to point out critical issues
>> with the Bloodhound proposal. I'm with Osimons for the most of his
>> gentle rambling against the massive effort for just the fork, and that
>> the true shape of the new project seem still very blurred and unclear.
>>
>> There is a saying: 'You know me by my actions, not by my words'. Among
>> other things it had been announced by Wandisco representatives, that
>> current (trac-hacks) developers and plugin maintainers would be
>> contacted to speak about possible ways of collaboration. While I felt
>> like this would qualify me at least for AccountManagerPlugin and
>> TagsPlugin, I've heard nothing by now.
>>
>> Not that I'd need that special attention. I don't complain at all. In
>> fact I would be a bit lost for words in the current situation. What
>> should I expect? What will be expected from the other side? I could
>> never compete to professionals doing it full-time as their daily
>> business. As a non-professional in the software development business I
>> can only dedicate a small part of my private life to work on Trac and
>> plugins, mostly late evenings, after children went to bed.
>>
>> Inside the Trac community this has never been a problem so far. Even
>> with initially very few coding experience I've found patient listeners
>> and professional advice on my requests here at the mailing list as well
>> as at #trac IRC channel. When I had a serious Trac problem and was in
>> doubt, if I could approach that or better give up, Simons hints and
>> encouraging words confirmed me to stay and try. Just one occasion that
>> I'll never forget.
>>
>> I'm thankful indeed and eager to give something back. My current plugin
>> maintainer status and loose affiliation with Trac core will continue, at
>> least until it is clear that Bloodhound will become the new Trac. But
>> this won't happen easily. Most announcements suggest effort that could
>> and maybe better should be done inside Trac and trac-hacks for more
>> livid development, and better packaging support by/with existing
>> operation system distributors on the other side.
>>
>> If you don't see my point here, just one more thought: Today
>> professional, key-turn application roll-outs are often virtual machines
>> in cluster setups. How could we encourage wider Trac adoption more
>> economic and sustainable within tight resource constraints, if not by
>> working closely with OS vendors? I don't see, that anyone here goes into
>> building images for VMware, VirtualBox, Xen & Co.
>>
>> I heartily welcome new developers joining here. Familiarize with the
>> Trac ecosystem, become a part of it. You'll be respected and encouraged
>> to take responsibility according to quantity and quality of
>> contributions as I witnessed several times by now. Having sponsors to
>> donate paid developer time could even yield a leap-frog progress at some
>> issues.
>>
>> OTOH a diversion won't be good for any of the involved parties. Trac
>> (plugin) developer base could be finally drained below the critical mass
>> to do both, maintain existing solutions and produce remarkable, valuable
>> new stuff. Just for getting the fame of Trac and respect of the
>> community for this project into the Apache domain? I hope this isn't the
>> hidden meaning of the Bloodhound proposal, and most probably it won't
>> work out in the end anyway.
>>
>> Would love to hear more people to speak-up here too.
>>
>> Steffen Hoffmann
>> (hasienda)
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL
>> j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg
>> =HhL5
>> -----END PGP SIGNATURE-----
>>
>> --
>> You received this message because you are subscribed to the Google
Groups "Trac Development" group.
>> To post to this group, send email to trac-***@googlegroups.com.
>> To unsubscribe from this group, send email to
trac-dev+***@googlegroups.com.
>> For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
"Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
trac-dev+***@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
"Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
trac-dev+***@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.



--
--
Ian Wild
Director of Engineering
WANdisco, Inc.

Cell : +44 (0)7961193722
Office DDI: +44 (0)114 3030472
US: +1 925 3801734

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ethan Jucovy
2011-12-25 21:37:03 UTC
Permalink
On Sun, Dec 25, 2011 at 3:45 PM, Ian Wild <***@wandisco.com> wrote:

> The Trac ethos is a fine one, which can be equated to an advanced assembly
> kit that people must put together in just the way they want before they can
> effectively use it. There are companies that offer pre-configured versions
> of Trac and professional services around it, but there is nothing that an
> average tools manager or evaluator can quickly test, use and deploy as part
> of an accessible open source package. That's not all there is to the Apache
> Bloodhound proposal, but it's important to highlight that there is a
> difference in approach and goal there. I personally don't believe either
> approach is wrong, just different.
>

+1. I think this is an excellent goal, and I think Trac is an excellent
base upon which to build it.


> The benefits that an open source foundation can bring to any project are
> well documented. As well as gaining an existing development and tools
> eco-system, the strong governance and very important legal protections that
> the Apache Software Foundation provide are not matched by the current Trac
> setup. As a business investing heavily in an open source project we are
> duty bound to ensure certain things about our investment. The impression we
> got from the existing 'core' of the Trac group was that they wouldn't be in
> a position to put those things in place and it was they who suggested that
> the best way forwards was a friendly fork.
>

Did these discussions with the Trac core developers happen on record? I
don't see any previous discussions about this on trac-dev or any of the
other obvious forums.

So now WANdisco is gathering a strong team who will work on this as part of
> a wider Apache based community. It isn't anyone's intention to detract from
> ongoing Trac development in anyway and I don't believe Apache Bloodhound
> will. As part of Apache there will be a community who would hope to take
> the best things from Trac, and I'm sure work to address the other points
> like Trac-hacks and the plugin eco-system among others. In no circumstances
> will we want to do that in a way which would undermines Trac though and I'd
> hope that all of these areas can be discussed and agreed upon as they are
> being approached.
>

Frankly the very act of importing a copy of the Trac core codebase,
relicensing it and rebranding it, and actively seeking out a community of
contributors to that project -- including from the existing pool of Trac
plugin developers -- seems unavoidably undermining, given the scarce
resources of time and attention.

It seems like the ideal scenario would be for an organization like the ASF
to provide the infrastructural and legal assurances for the Trac core as
the Trac core, and for a commercial organization like WANdisco to build its
products on top of that. I understand that this isn't very far off from
what's happening here, and I can certainly see how expedience might favor
the solution you've arrived at. But the particular details that diverge
from that ideal (starting from a fork of the core code; apparently
rebranding a combination of that core fork + a configuration of it; and the
licensing issues) seem quite important.

I appreciate your intention to work on these questions with the Trac
community going forward. But this could easily devolve into a
chicken-and-egg problem where the expedient solution ends up remaining in
place and we end up with two codebases, two brands, two licenses, two
communities and two "core design philosophies" for good. To prevent that,
I hope that we can quickly develop a clear picture of what roadblocks stand
in the way of the ideal solution, and that there can be a clear and ongoing
conversation about how we all might reach that end goal as the project
develops. As a Trac user, plugin author, and sometimes-evangelist, seeing
an effort to develop that particular roadmap up front -- on both the
technical and nontechnical (e.g. legal and governance) sides -- would
alleviate a lot of my fears about this effort and make me much more
inclined to get involved.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-25 22:53:01 UTC
Permalink
On Sun, Dec 25, 2011 at 9:37 PM, Ethan Jucovy <***@gmail.com>wrote:

Did these discussions with the Trac core developers happen on record? I
> don't see any previous discussions about this on trac-dev or any of the
> other obvious forums.
>

Although there was nothing inherently private about the discussions, they
were predominantly held by email and a number of conference calls. At that
time we were in a discovery mode and there were other commercial entities
engaged in the same discussions. It wouldn't be appropriate for me to
republish those threads verbatim, but I don't think there was anything
controversial or that won't be / hasn't been repeated here.

Frankly the very act of importing a copy of the Trac core codebase,
> relicensing it and rebranding it, and actively seeking out a community of
> contributors to that project -- including from the existing pool of Trac
> plugin developers -- seems unavoidably undermining, given the scarce
> resources of time and attention.
>

I understand the argument, but I don't believe thats what will happen. I
can imagine that Apache Bloodhound might result in new life for some
plugins, or even the contribution of new ones, but I just don't believe the
efforts will be conflicting or negative to the Trac base. If the Apache
incubator succeeds in growing a strong new community for Apache Bloodhound
it will almost certainly serve to strengthen the Trac code and plugins too.
It's too early to talk about specifics, but there are plenty of precedents
with positive outcomes from similar situations.


> It seems like the ideal scenario would be for an organization like the ASF
> to provide the infrastructural and legal assurances for the Trac core as
> the Trac core, and for a commercial organization like WANdisco to build its
> products on top of that. I understand that this isn't very far off from
> what's happening here, and I can certainly see how expedience might favor
> the solution you've arrived at. But the particular details that diverge
> from that ideal (starting from a fork of the core code; apparently
> rebranding a combination of that core fork + a configuration of it; and the
> licensing issues) seem quite important.
>

This was our original suggestion. Somewhat understandably, because we
hadn't been involved with Trac development previously, the view was 'you
are free to do what you wish, but we will wait and see'. Trac as a project
has longevity, users, reputation and plenty to keep it doing what it's
doing. The good thing about this approach is that the proposal doesn't
impact the course the existing Trac leadership is steering but the options
remain open in terms of future developments.


> I appreciate your intention to work on these questions with the Trac
> community going forward. But this could easily devolve into a
> chicken-and-egg problem where the expedient solution ends up remaining in
> place and we end up with two codebases, two brands, two licenses, two
> communities and two "core design philosophies" for good.
>

Completely agree - it would be helpful to discuss this further. If we end
up in a place where there's a conflict between the communities then
something went wrong. Would there be interest in an open telephone
conference in the new year to discuss these things in more detail? Maybe
it's just me, but with so much to talk about, I find email a rather
difficult medium to work with.

Best Wishes,

Ian

--
Ian Wild
Director of Engineering
WANdisco, Inc.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Andy Baker
2011-12-25 23:04:56 UTC
Permalink
Amen the email comment and the open discussion, but the conference
call suggestion doesn't work for the community (IMO). Notwithstanding
the need to get all interested parties together at the same time, the
last time I tried an online WANdisco conference thing I was excluded
because I wasn't running Windoze (Cisco conf system). Doesn't fill me
with confidence.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-25 23:29:07 UTC
Permalink
On Sun, Dec 25, 2011 at 11:04 PM, Andy Baker <***@gmail.com> wrote:

> Amen the email comment and the open discussion, but the conference
> call suggestion doesn't work for the community (IMO). Notwithstanding
> the need to get all interested parties together at the same time, the
> last time I tried an online WANdisco conference thing I was excluded
> because I wasn't running Windoze (Cisco conf system). Doesn't fill me
> with confidence.
>
>
Very true, it can be difficult to organise such calls. It was just an idea
to get things moving anyway. Even a smaller call which doesn't attempt to
represent everyone can still be effective at progressing things.

Agree with you on Gotomeeting btw - It finally now supports OSX, but as a
long time Ubuntu desktop user myself it's a bit of a fail. I guess the
marketing team can't find anything better.

Ian

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Greg Troxel
2011-12-25 23:49:52 UTC
Permalink
Ian Wild <***@wandisco.com> writes:

> Agree with you on Gotomeeting btw - It finally now supports OSX, but as a
> long time Ubuntu desktop user myself it's a bit of a fail. I guess the
> marketing team can't find anything better.

Asking people in the open source community to use proprietary tools to
interact is just broken. If you can't figure out a 100% open source
conferencing solution, then you just don't do it - rather than saying
the proprietary tools are the best available. I was asked, as a
maintainer of an entirely unrelated free software project, to be on a
"conference call" using non-free tools - and I simply declined to
participate. (Expecting people that you pay for their time to use
non-free tools is another matter; I'm talking about people in a free
software community that don't owe you anything.)
Andy Baker
2011-12-26 00:02:19 UTC
Permalink
Bit of a shocker Ian, OS proponent company can't find OS conferencing
solution '-) I had to send people down to your conference in person to
try and make sense of where you were going. Was it Heathrow last year?
Still, bless 'em, they brought me a t-shirt.

I hear the "getting things moving" and I'm cool with that, but who
gets left behind as you move things on? I dunno, you may have a hard
core cabal already and us part timer's will just have to go with the
flow or fork ourselves (no pun intended).

Needs to be a bit more open for my liking.



On 25 December 2011 23:29, Ian Wild <***@wandisco.com> wrote:
> On Sun, Dec 25, 2011 at 11:04 PM, Andy Baker <***@gmail.com> wrote:
>>
>> Amen the email comment and the open discussion, but the conference
>> call suggestion doesn't work for the community (IMO). Notwithstanding
>> the need to get all interested parties together at the same time, the
>> last time I tried an online WANdisco conference thing I was excluded
>> because I wasn't running Windoze (Cisco conf system). Doesn't fill me
>> with confidence.
>>
>
> Very true, it can be difficult to organise such calls. It was just an idea
> to get things moving anyway. Even a smaller call which doesn't attempt to
> represent everyone can still be effective at progressing things.
>
> Agree with you on Gotomeeting btw - It finally now supports OSX, but as a
> long time Ubuntu desktop user myself it's a bit of a fail. I guess the
> marketing team can't find anything better.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+***@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Andy Baker
2011-12-26 00:05:14 UTC
Permalink
May have been mentioned already (email threads are impossible) but has
anyone raised the agile42 thing?

On 26 December 2011 00:02, Andy Baker <***@gmail.com> wrote:
> Bit of a shocker Ian, OS proponent company can't find OS conferencing
> solution '-) I had to send people down to your conference in person to
> try and make sense of where you were going. Was it Heathrow last year?
> Still, bless 'em, they brought me a t-shirt.
>
> I hear the "getting things moving" and I'm cool with that, but who
> gets left behind as you move things on? I dunno, you may have a hard
> core cabal already and us part timer's will just have to go with the
> flow or fork ourselves (no pun intended).
>
> Needs to be a bit more open for my liking.
>
>
>
> On 25 December 2011 23:29, Ian Wild <***@wandisco.com> wrote:
>> On Sun, Dec 25, 2011 at 11:04 PM, Andy Baker <***@gmail.com> wrote:
>>>
>>> Amen the email comment and the open discussion, but the conference
>>> call suggestion doesn't work for the community (IMO). Notwithstanding
>>> the need to get all interested parties together at the same time, the
>>> last time I tried an online WANdisco conference thing I was excluded
>>> because I wasn't running Windoze (Cisco conf system). Doesn't fill me
>>> with confidence.
>>>
>>
>> Very true, it can be difficult to organise such calls. It was just an idea
>> to get things moving anyway. Even a smaller call which doesn't attempt to
>> represent everyone can still be effective at progressing things.
>>
>> Agree with you on Gotomeeting btw - It finally now supports OSX, but as a
>> long time Ubuntu desktop user myself it's a bit of a fail. I guess the
>> marketing team can't find anything better.
>>
>> Ian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Trac Development" group.
>> To post to this group, send email to trac-***@googlegroups.com.
>> To unsubscribe from this group, send email to
>> trac-dev+***@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/trac-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-26 10:59:07 UTC
Permalink
Am 26.12.2011 01:05, schrieb Andy Baker:
> May have been mentioned already (email threads are impossible) but has
> anyone raised the agile42 thing?

What's the "agile42 thing"? And no, it hasn't been mentioned so far.

fs

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Benjamin Lau
2011-12-26 11:47:24 UTC
Permalink
I think that's referring to:
http://agilosoftware.com/

They produced a modified version of trac tuned for "agile" process. If I
remeber correctly they added some facility for manging stories (use cases
if you don't know agile terminology). Hadn't heard much about it in a few
years. Was evaluating it for a previous employer... We opted to roll our
own solution on top of trac.

Ben
On Dec 26, 2011 2:59 AM, "Felix Schwarz" <***@oss.schwarz.eu>
wrote:

>
>
> Am 26.12.2011 01:05, schrieb Andy Baker:
> > May have been mentioned already (email threads are impossible) but has
> > anyone raised the agile42 thing?
>
> What's the "agile42 thing"? And no, it hasn't been mentioned so far.
>
> fs
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+***@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-26 13:44:29 UTC
Permalink
Am 26.12.2011 12:47, schrieb Benjamin Lau:
> I think that's referring to:
> http://agilosoftware.com/

I'm aware of agile42 and Agilo (as was one of the previous developers) but I'm
unsure how this is related to the WANdisco approach now?

fs



--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Andy Baker
2011-12-25 20:54:28 UTC
Permalink
My $0.02? It smells a bit.

On the face of it WANdisco could be a force for good, but even if you
trust who they are now, can you trust who they might be in a years
time? Do they even know? Commercial organisations can come in with the
very best of intentions, but the world (and people) move on.

I fully endorse the "take the open source for free; buy the support"
model but it just makes me twitchy when people jump in like this. Call
me an old woolly *nix liberal, but something just sticks in the
throat. I guess in the same kinda way I'm now postgres not mysql,

My background is a cut'n'shut CVS/Subversion/Mantis/Trac. I confess
I've contributed little back to Trac other than the odd bugfix and
occasional comment on the usergroup but I suspect I'm like many back
seat drivers around here who would speak up and fight if it came to
it.

FWIW!
Andy

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-25 21:02:49 UTC
Permalink
Am 25.12.2011 21:54, schrieb Andy Baker:
> On the face of it WANdisco could be a force for good, but even if you
> trust who they are now, can you trust who they might be in a years
> time? Do they even know? Commercial organisations can come in with the
> very best of intentions, but the world (and people) move on.

Well, that's one of the things which are handled by the Apache software
foundation. The source is still free software and with the Apache License
there is even a limited patent protection clause. If WANdisco looses interest
in Bloodhound, the project still lives as long as there are other contributors
(which is one of the explicitely stated goals of the Apache proposal).

My biggest concern with Bloodhound currently (from a Trac perspective) is the
license incompatibility as it won't be possible to incorporate code from
Bloodhound into Trac (AFAIK all new code will be Apache-licensed).

fs

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Andy Baker
2011-12-25 21:26:21 UTC
Permalink
Frankly I've been using the "seasonal break" to catch up on these
things so my take on the situation is knee jerk and buckshot at best;
only read about this an hour ago! (forgive me I've been off in
Drupal-land recently arguing about Trac/Drupal integration <yawn>).
Just felt a burning desire to stick my oar in.

This may be a stupid idea, so feel free to shoot me down in flames
people, but is there an argument to set up a quick'n'dirty forum to
thrash these things out in the open air? Maybe it's just me, but I
struggle to keep track of mailing lists; web based or otherwise.

On 25 December 2011 21:02, Felix Schwarz <***@oss.schwarz.eu> wrote:
>
> Am 25.12.2011 21:54, schrieb Andy Baker:
>> On the face of it WANdisco could be a force for good, but even if you
>> trust who they are now, can you trust who they might be in a years
>> time? Do they even know? Commercial organisations can come in with the
>> very best of intentions, but the world (and people) move on.
>
> Well, that's one of the things which are handled by the Apache software
> foundation. The source is still free software and with the Apache License
> there is even a limited patent protection clause. If WANdisco looses interest
> in Bloodhound, the project still lives as long as there are other contributors
> (which is one of the explicitely stated goals of the Apache proposal).
>
> My biggest concern with Bloodhound currently (from a Trac perspective) is the
> license incompatibility as it won't be possible to incorporate code from
> Bloodhound into Trac (AFAIK all new code will be Apache-licensed).
>
> fs
>
> --
> You received this message because you are subscribed to the Google Groups "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2011-12-26 22:53:54 UTC
Permalink
On 12/25/2011 10:02 PM, Felix Schwarz wrote:
> My biggest concern with Bloodhound currently (from a Trac perspective) is the
> license incompatibility as it won't be possible to incorporate code from
> Bloodhound into Trac (AFAIK all new code will be Apache-licensed).
>

AFAICT, there's no license incompatibility.

We have a 3-clause BSD license, which is acceptable for Apache, so they
don't need to change the license for the initial code base or for later
updates coming from t.e.o. Indeed, they plan to place only the new code
they'll be writing under ALv2, as Greg Stein wrote in [1].

If we want to take Bloodhound code into Trac, I don't see any problem
either, as the ALv2 explicitly allows redistribution of the code even
under a different license ("You may distribute the result under a
different license, but you need to acknowledge the use of the
Foundation's software", from [2]). So if we do so, we'll just need to
say something like "contains code from Apache Foundation" at some
appropriate place.

-- Christian

[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCABD8fLXs%2BCz3qQkR20bS2%2BSAW0N3yiTGkTH7iTxGwTUUwTADSQ%40mail.gmail.com%3E

[2] http://www.apache.org/foundation/license-faq.html#Distribute-changes

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-28 11:45:16 UTC
Permalink
Am 26.12.2011 23:53, schrieb Christian Boos:
> If we want to take Bloodhound code into Trac, I don't see any problem either,
> as the ALv2 explicitly allows redistribution of the code even under a
> different license ("You may distribute the result under a different license,
> but you need to acknowledge the use of the Foundation's software", from [2]).
> So if we do so, we'll just need to say something like "contains code from
> Apache Foundation" at some appropriate place.

Not sure if that's true.

"Even if you change every single line of the Apache code you're using, the
result is still based on the Foundation's licensed code. You may distribute
the result under a different license, but you need to acknowledge the use of
the Foundation's software."
http://www.apache.org/foundation/license-faq.html#Distribute-changes

Probably it's just my English but I'm not sure if the 'You may distribute the
result under a different license' applies only to the previous sentence ("if
you change every single line of the Apache code").

The paragraph says also:
"I've made improvements to the Apache code; may I distribute the modified result?

Absolutely -- subject to the terms of the Apache license, of course. (...)
Just remember that the original code is still covered by the Apache license
and you must comply with its terms."

However I assume that's a pretty easy question for Apache's laywers so we can
just wait for their correct(tm) interpretation.

fs

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
John Hampton
2011-12-28 19:08:32 UTC
Permalink
On Wed, Dec 28, 2011 at 3:45 AM, Felix Schwarz <***@oss.schwarz.eu
> wrote:

> "Even if you change every single line of the Apache code you're using, the
> result is still based on the Foundation's licensed code. You may distribute
> the result under a different license, but you need to acknowledge the use
> of
> the Foundation's software."
> http://www.apache.org/foundation/license-faq.html#Distribute-changes
>
> Probably it's just my English but I'm not sure if the 'You may distribute
> the
> result under a different license' applies only to the previous sentence
> ("if
> you change every single line of the Apache code").
>

Of course, the standard IANAL disclaimer applies, however, as one that does
have a good grasp of English, the "Even" at the beginning of the sentence
gives credence to Christian's interpretation. It implies that once can
change all the code, but need not to. The amount of code that changes in
this case is irrelevant. One line, all lines, or any number of lines, The
result is still based on Foundation code. Said result can then be
redistributed under another license as along as one "acknowledges the use
of Foundation software".

This is how I would expect a normal, native English speaker to interpret
the paragraph above.

-John

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ethan Jucovy
2011-12-30 22:14:07 UTC
Permalink
I've posted a response to the proposal on the Apache Incubator list:

http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAMmgw9k95CAcZpgaO%2BW0_cuLLWVgx3cDqebNby%3DwoZ9L%3D%2BYr3A%40mail.gmail.com%3E

As I said earlier in this thread, I'm all for more Trac distributions, but
between the significant unresolved questions about community interactions,
license compatibilities, and how to ensure this project remains symbiotic
with Trac; the proposal's misrepresentations about the Trac community's
procedures; and the lack of any clear, specific statements to date as to
why Bloodhound must resort to a fork, I think this project would be much
more likely to succeed and to have a healthy relationship with Trac if
these issues are addressed before it moves forward.

-Ethan

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2011-12-30 23:27:43 UTC
Permalink
On 12/30/2011 11:14 PM, Ethan Jucovy wrote:
> I've posted a response to the proposal on the Apache Incubator list:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAMmgw9k95CAcZpgaO%2BW0_cuLLWVgx3cDqebNby%3DwoZ9L%3D%2BYr3A%40mail.gmail.com%3E
>
> As I said earlier in this thread, I'm all for more Trac distributions,
> but between the significant unresolved questions about community
> interactions, license compatibilities, and how to ensure this project
> remains symbiotic with Trac; the proposal's misrepresentations about the
> Trac community's procedures; and the lack of any clear, specific
> statements to date as to why Bloodhound must resort to a fork, I think
> this project would be much more likely to succeed and to have a healthy
> relationship with Trac if these issues are addressed before it moves
> forward.
>


Well, the vote was already closed the 22th of December and Bloodhound is
now "incubating"
(http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAJjMeYPPbzC_-mcE8uB0sp6coVWjvCLVB+***@mail.gmail.com%3E).

It will nevertheless be instructive to read the answers to your post.

-- Christian

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Dirk Stöcker
2011-12-30 23:53:49 UTC
Permalink
On Sat, 31 Dec 2011, Christian Boos wrote:

> Well, the vote was already closed the 22th of December and Bloodhound is now
> "incubating"
> (http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAJjMeYPPbzC_-mcE8uB0sp6coVWjvCLVB+***@mail.gmail.com%3E).
>
> It will nevertheless be instructive to read the answers to your post.

It is a bit strange to make decisions without counting the opinion
of affected people in their own communication system (i.e. this
mailinglist).

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
osimons
2011-12-31 00:57:14 UTC
Permalink
On Dec 31, 12:53 am, Dirk Stöcker <***@dstoecker.de> wrote:
> On Sat, 31 Dec 2011, Christian Boos wrote:
> > Well, the vote was already closed the 22th of December and Bloodhound is now
> > "incubating"
> > (http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CC AJjMeYPPbzC_-mcE8uB0sp6coVWjvCLVB+***@mail.gmail.com%3E).
>
> > It will nevertheless be instructive to read the answers to your post.
>
> It is a bit strange to make decisions without counting the opinion
> of affected people in their own communication system (i.e. this
> mailinglist).

Well, up until the conclusion of the vote all publicly expressed
sentiment on this mailing list was some variation of "cool, good luck"
- which is the Trac community's default positive response to anyone
wanting to invest time and resources to work with Trac in any form. We
are very naive in that respect, but then again we can afford to seeing
we are not players in any form of corporate or foundation power play.

Nor is it our responsibility to feed the Apache incubator mailing list
with reason or discussion - it is not our project and they are grown-
ups that make their own decisions, for good or bad. If anyone at
Apache Incubator level had any uncertainly about the information
provided or felt it needed verification or more details, surely they
would just have asked someone? Anyone aware of Trac development would
be able to provide pointers to people to poke for information, and any
one of us would gladly offer our advice.

Their software foundation, their incubator, their proposal, their
project. They got to figure this out.


:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com


--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
DavidRichards
2011-12-31 02:24:44 UTC
Permalink
Hi everyone. I'm David from WANdisco.

I've just read some of the posts here and I think it's worth just
clarifying a couple of points.

1. If a corporation, such as WANdisco, wanted to take control of an
open source project then the *last* place to do it would be as part of
the ASF (Apache Software Foundation). For those not familiar with the
ASF I would recommend reading this http://www.apache.org/foundation/how-it-works.html.

Henrik Ingo wrote a very interesting piece (http://openlife.cc/blogs/
2010/november/how-grow-your-open-source-project-10x-and-revenues-5x)
last year about successful open source projects. Henrik concludes "an
obvious recommendation that vendors participating in open source
development and business, should look into participating in
collaborative community developed projects - where the standard and
familiar governance form is a non-profit foundation. If a vendor is
currently in control of an open source project, it should explore the
option of transferring the project to an existing foundation, or
alternatively creating its own foundation for it. Since the original
vendor is always the strongest candidate to become the leading vendor
also in a collaboratively developed project, the vendor could, as a
rule of thumb, expect this strategy - if properly executed - to result
in a 10x growth in the project and product, but also 10x larger
addressable market, of which the vendor can expect to capture 50% or
more as its own market share."

2. Apache 2.0 is a *very* permissive license. Quoting Apache "The
goals of this license revision have been to reduce the number of
frequently asked questions, to allow the license to be reusable
without modification by any project (including non-ASF projects), to
allow the license to be included by reference instead of listed in
every file...The result is a license that is supposed to be compatible
with other open source licenses, while remaining true to the original
goals of the Apache Group and supportive of collaborative development
across both nonprofit and commercial organizations."

A number of (inaccurate) comments related to license compatibility
have been posted here so I think it's worth reading the Apache 2.0
license FAQ. The FAQ on the license can be found here:
http://www.apache.org/foundation/license-faq.html

But the key to understand the legalese is:

I'm not a lawyer. What does it all MEAN?
Describing legal documents in non-legalese is fraught with potential
for misinterpretation. Notwithstanding the text that follows, the
actual text of the license itself is legally binding and
authoritative.

That said, here's what the Apache license says in layman's terms:

It allows you to:

freely download and use Apache software, in whole or in part, for
personal, company internal, or commercial purposes;

use Apache software in packages or distributions that you create.

It forbids you to:

redistribute any piece of Apache-originated software without proper
attribution;

use any marks owned by The Apache Software Foundation in any way that
might state or imply that the Foundation endorses your distribution;

use any marks owned by The Apache Software Foundation in any way that
might state or imply that you created the Apache software in question.

It requires you to:

include a copy of the license in any redistribution you may make that
includes Apache software;

provide clear attribution to The Apache Software Foundation for any
distributions that include Apache software.

It does not require you to:

include the source of the Apache software itself, or of any
modifications you may have made to it, in any redistribution you may
assemble that includes it;

submit changes that you make to the software back to the Apache
Software Foundation (though such feedback is encouraged).

3. Prior to embarking on the Bloodhound effort we did talk to
Christian and Remy on several occasions. They are great guys. They do
the vast majority of the development effort on Trac today. But it's
pretty difficult with only 2 active developers - that is *not* a
criticism by the way. Priorities change and people move on to other
things. Ohloh have a decent view on the stats: http://www.ohloh.net/p/trac

Because of this and the fact that Edgwall's current status is "fuzzy"
we decided that our contribution should be as part of a larger,
independent entity. In addition our experience of Subversion in an
ASF context has been extremely positive. Our open source Subversion
developers only develop Subversion. The same will apply to Apache
Bloodhound.

4. We did extensive research and we really like Trac. Obviously or we
wouldn't be embarking on a project based on Trac right? We do have a
belief that the core should be a little larger than it is today and
some 'key' plug-ins should be included. We also believe it should
support multiple projects. I realize that having a larger core does
conflict with some businesses out there where the proprietors are
solving the problem of keeping "close track on all development and
issues for all the components you use to run the system... 10+
components often with monthly release cycles."

5. The reason for the friendly-fork? During discussion with Edgwall
this was a suggested approach. It's not negative, in fact the
assumption was that a friendly-fork would be well received by a
community looking for improvements to multi-project support and other
things. I guess the important thing here is that this is a *friendly*
fork and this was a suggested approach.



I will conclude by saying that the Apache Bloodhound project will be
open to anyone to participate. To again quote the ASF "We firmly
believe in hats. Your role at the ASF is one assigned to you
personally, and is bestowed on you by your peers. It is not tied to
your job or current employer or company."

The next step for us is to build a great product and community. We
are not competing with Trac or anything else for that matter. Our
goal is simple. Build the best defect tracker in the world.

My only request here is to stick with facts and try to avoid
scaremongering. Ian Wild, WANdisco's head of engineering is happy to
answer any questions any of you may have. Remy & Christian have
answered your quesries pretty well in this thread and I would strongly
urge you to use them as the 'go-to guys' from Trac.

happy new year everyone!

- David Richards
President & CEO, WANdisco

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-31 09:43:53 UTC
Permalink
Hi David,

thanks for your input here.

Am 31.12.2011 03:24, schrieb DavidRichards:
> 2. Apache 2.0 is a *very* permissive license. (...)

Unfortunately I think you miss the point of the licensing issues from the Trac
side. Of course Apache is very liberal and it wouldn't be a problem for Trac
to depend on a Apache-licensed package.

IMHO the question is if Trac can take an Apache-licensed file (for example)
and put it in Trac, distributing it under the terms of the BSD license and not
under the Apache license (though with acknowledgement + the original source in
the original repo is still Apache of course).

>From my naive understanding this requires the right to relicense which no free
software license gives you (unless you're the copyright owner).

Otherwise Trac is licensed under 'BSD + Apache' (most files under BSD, some
Apache) which effectively makes it 'Apache' for the complete source code (as
it is nearly impossible to deal with licensing on a file/hunk level). Also
this is a pain when comes to license auditing: different licenses within the
same body of source code are a great mess unless you pick the most restrictive
license and assume the whole code is under that license (e.g. Apache+BSD code
in GPL software -> assume GPL for every file and you won't violate the
Apache/BSD licenses).

Probably I'm too picky here but I still hope we can get an Apache laywer's
input with a clear answer to the question :-)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-31 11:44:51 UTC
Permalink
On Sat, Dec 31, 2011 at 9:43 AM, Felix Schwarz <***@oss.schwarz.eu
> wrote:

Probably I'm too picky here but I still hope we can get an Apache laywer's
> input with a clear answer to the question :-)
>

Hi Felix,

I don't think Greg Stein will mind me quoting him as an authoritative voice
on the subject (Greg is a Vice Chairman of Apache and very experienced in
this area). He was involved in some of the original discussion in May and
answered a question along the same lines:

> Regarding the use of the Apache license I'm a bit skeptical. Since Trac
> (core) is 100% BSD, it wouldn't make much sense in accepting non-BSD
> code contributions. But I'm not a lawyer, maybe there's ways around
that...

The Apache License, v2, is compatible with BSD and GPLv3. It is a
permissive license, like BSD, but has been modernized to account for
the explicit rights under current copyright law. It also deals well
with patents and incidental contributions from people. IOW, same
philosophy, but tighter language.

Should the decision be to create a "friendly fork", then carrying
changes back and forth will still allow the overall package to be
delivered under a permissive license. It is simply that parts will be
BSD and parts will be ALv2.

The choice of ALv2 is pragmatic: should the code end up at the ASF,
then using ALv2 will be mandatory for the overall package (and the ASF
allows incorporating BSD into the package).

I hope that helps, but would be happy to answer more questions and
concerns about licensing.

Cheers,
-g

I believe this clarifies things sufficiently? This is a pretty well trodden
path and the bottom line is that it is possible for Trac to keep
distributing under a BSD license while incorporating Apache licensed code
if thats how it pans out.

Best Wishes,

Ian
--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Dirk Stöcker
2011-12-31 12:15:46 UTC
Permalink
On Sat, 31 Dec 2011, Ian Wild wrote:

> I believe this clarifies things sufficiently? This is a pretty well
> trodden path and the bottom line is that it is possible for Trac to keep
> distributing under a BSD license while incorporating Apache licensed
> code if thats how it pans out.

Actually it says Trac either needs to switch to Apache license or
cannot use any code from the fork. This is the opposite of what you say.

As Felix already said, maintaining license on file level is impossible and
also would prevent structures or functions to be copied - normally patches
do not consist of singular files.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-31 12:50:07 UTC
Permalink
On Sat, Dec 31, 2011 at 12:15 PM, Dirk Stöcker <***@dstoecker.de> wrote:

Actually it says Trac either needs to switch to Apache license or cannot
> use any code from the fork. This is the opposite of what you say.
>

"Carrying changes back and forth will still allow the overall package
to be delivered
under a permissive license. It is simply that parts will be BSD and parts
will be ALv2."

Where does that say that Trac would need to switch to an Apache license to
use code licensed under ALv2?

As Felix already said, maintaining license on file level is impossible and
> also would prevent structures or functions to be copied - normally patches
> do not consist of singular files.


Assuming the Trac project wants to take Apache Bloodhound code, why is
shipping the Apache v2 license file and adding an appropriate attribution
in the form of a boilerplate to any file that contains Apache licensed code
'impossible'?

The Apache FAQ[1] provides a clear understanding of this to me. Perhaps you
could restate exactly where the confusion is coming from?

Best Wishes,

Ian

[1] http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ethan Jucovy
2011-12-31 13:00:59 UTC
Permalink
Ian,

On Sat, Dec 31, 2011 at 7:50 AM, Ian Wild <***@wandisco.com> wrote:

> Assuming the Trac project wants to take Apache Bloodhound code, why is
> shipping the Apache v2 license file and adding an appropriate attribution
> in the form of a boilerplate to any file that contains Apache licensed code
> 'impossible'?
>

Felix's previous message explains this:

> Otherwise [barring a right to relicense] Trac is licensed under 'BSD +
Apache' (most files under BSD, some
> Apache) which effectively makes it 'Apache' for the complete source code
(as
> it is nearly impossible to deal with licensing on a file/hunk level). Also
> this is a pain when comes to license auditing: different licenses within
the
> same body of source code are a great mess unless you pick the most
restrictive
> license and assume the whole code is under that license (e.g. Apache+BSD
code
> in GPL software -> assume GPL for every file and you won't violate the
> Apache/BSD licenses).

I see that this same point also came up on the Apache Incubator discussion
thread[1]. Marvin Humphrey said:

> Presumably there will be significant modifications to the BSD codebase by
> Apache contributors as time goes along. If these modifications fall
under the
> ALv2, then files with a BSD license header will contain a mix of ALv2 and
BSD
> code. Short of maintaining our contributions as diffs :) how are we to
> communicate which parts of the files fall under BSD and which parts fall
under ALv2?

These considerations were not addressed in the subsequent conversation on
that list.

-Ethan

[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3C20111210185539.GA28129%40rectangular.com%3E

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Dirk Stöcker
2011-12-31 13:06:06 UTC
Permalink
On Sat, 31 Dec 2011, Ian Wild wrote:

>> Actually it says Trac either needs to switch to Apache license or
>> cannot use any code from the fork. This is the opposite of what you say.
>
> "Carrying changes back and forth will still allow the overall package to
> be delivered under a permissive license. It is simply that parts will be
> BSD and parts will be ALv2."
>
> Where does that say that Trac would need to switch to an Apache license
> to use code licensed under ALv2?

When a file-based license situation is impossible, then you will need to
stick to one license. As BSD can become ALv2, but ALv2 cannot become BSD,
the Trac product must be ALv2 when code is copied.

Even when really doing file-exact licensing (and believe me, nobody really
wants this), each copied patch would change one more file into ALv2 - in
the end everything would be ALv2.

The is only one situation, where dual licensing works: When all code is
released under both licenses.

>> As Felix already said, maintaining license on file level is impossible
>> and also would prevent structures or functions to be copied - normally
>> patches do not consist of singular files.

> Assuming the Trac project wants to take Apache Bloodhound code, why is
> shipping the Apache v2 license file and adding an appropriate
> attribution in the form of a boilerplate to any file that contains
> Apache licensed code 'impossible'?

Ok. It is not "impossible". It is "undoable". A programmer is no lawyer
and nobody I know doing software development in his free time wants to
care for this. The result would be that after probably one year of copying
code the license situation would be so confused, that nobody knows which
files are licensed how. Again the result would be to switch everything to
ALv2.

I know the trouble I had with JOSM to find out whether the code is
"GPLv2+" or "GPLv2 only", which is a major difference and this is only one
license.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2012-01-02 23:03:05 UTC
Permalink
On 12/31/2011 2:06 PM, Dirk Stöcker wrote:
> On Sat, 31 Dec 2011, Ian Wild wrote:
>> Assuming the Trac project wants to take Apache Bloodhound code, why is
>> shipping the Apache v2 license file and adding an appropriate
>> attribution in the form of a boilerplate to any file that contains
>> Apache licensed code 'impossible'?
>
> Ok. It is not "impossible". It is "undoable". A programmer is no lawyer
> and nobody I know doing software development in his free time wants to
> care for this. The result would be that after probably one year of
> copying code the license situation would be so confused, that nobody
> knows which files are licensed how. Again the result would be to switch
> everything to ALv2.

Even if more and more files would end up being ALv2 (only ALv2 for new
files, BSD + ALv2 for modified files?), the result as a whole could
still be licensed as BSD (as long as it's modified code, and it will
be as at the very least we will have "less" bundled plugins), and
provided we stick with the *terms* of the ALv2 license, i.e. carry the
LICENSE file somehow (contrib/LICENSE.Bloodhound?) and give proper
attributions that we used code from Apache (in a new NOTICE file).

But you're right, this might prove painful and could have been avoided
had they stuck to the same license as ours. For example, some people
pick only our wonderful plugin system in trac/core.py and a few other
files, other pick some of our utilities. So far it's simple for them,
we're a BSD project compatible with almost everything. What if now
they have to carefully look if what they take is BSD, BSD + ALv2 or
ALv2 only? Not impossible but harder than it is now. Of course, *we*
could switch to ALv2, but such a move is hard to justify beforehand,
and I think it will only happen if there's a really compelling reason
to do so.

Besides, even if the license would be the same, another concern is the
Apache policy related to contributor license agreements. I now wonder
if the Bloodhound project will even able to integrate our changes back
into their contributed and modified files (in a kind of "regularly
merge from upstream" workflow), as the changes contributed to Trac
typically won't be accompanied by a CLA [3] for Apache. Indeed, we
already have trouble getting our contributors to bother writing a
proper commit message, so let alone sign and send such paperwork ;-)
But they also never said they even *wanted* to do this, so far. If
they don't integrate our changes, then yes, the two code bases could
likely diverge after a while and it would prove difficult to stay
compatible.

So I'm not sure anymore. Perhaps my initial view that we could just
take their code (if it would be pertinent to do so based on its own
merit or for easing compatibility) was just misguided. Maybe the
split of licenses and policies regarding CLAs really doesn't make it
that realistic to share the code.

If that's the case, then we just won't take any modifications from
Bloodhound and we'll move on. This is of course fine by me, but it
would be better to have the answers to the questions above, in order
to know whether it's worth for us (as Trac maintainers) to spend some
time watching the Bloodhound project or not.

>
> I know the trouble I had with JOSM to find out whether the code is
> "GPLv2+" or "GPLv2 only", which is a major difference and this is only
> one license.
>

Right, the GPL is even a bit more complicated to deal with... Except
for one thing: once it's GPL, all derived work needs to be GPL as well
so with that license we wouldn't have had the kind of complications
we're now seeing here with the more "liberal" licenses ;-)

-- Christian

[1]
https://svn.apache.org/repos/asf/gump/trunk/python/gump/core/commandLine.py
[2] http://www.apache.org/licenses/LICENSE-2.0.txt
[3] http://www.apache.org/licenses/icla.txt

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Greg Stein
2012-01-03 01:02:33 UTC
Permalink
On Monday, January 2, 2012 6:03:05 PM UTC-5, Christian Boos wrote:
>
> On 12/31/2011 2:06 PM, Dirk Stï¿œcker wrote:
> > On Sat, 31 Dec 2011, Ian Wild wrote:
> >> Assuming the Trac project wants to take Apache Bloodhound code, why is
> >> shipping the Apache v2 license file and adding an appropriate
> >> attribution in the form of a boilerplate to any file that contains
> >> Apache licensed code 'impossible'?
> >
> > Ok. It is not "impossible". It is "undoable". A programmer is no lawyer
> > and nobody I know doing software development in his free time wants to
> > care for this. The result would be that after probably one year of
> > copying code the license situation would be so confused, that nobody
> > knows which files are licensed how. Again the result would be to switch
> > everything to ALv2.

Even if more and more files would end up being ALv2 (only ALv2 for new
> files, BSD + ALv2 for modified files?),
>
Right: all current files would remain BSD, and would be modified under that
license. New files created by committers at the ASF would fall under ALv2,
and be noted as such in their header. We would be attaching a LICENSE file
with the ALv2, and a NOTICE file that notes that portions are available
under the BSD license (under whatever copyright). The ASF will leave any
existing copyright notices in the file headers. It may prepend a small
notice above that to refer people to the overall package license and NOTICE
file; I don't know the plan right now.

It isn't too hard to keep track of licensing on a per-file basis, as you
simply look in the header.

the result as a whole could
> still be licensed as BSD (as long as it's modified code, and it will
> be as at the very least we will have "less" bundled plugins), and
> provided we stick with the *terms* of the ALv2 license, i.e. carry the
> LICENSE file somehow (contrib/LICENSE.Bloodhound?) and give proper
> attributions that we used code from Apache (in a new NOTICE file).
>
That sounds just right.

Apache Bloodhound is released as a whole under the ALv2, and incorporates
some work under the BSD. If Trac chooses to incorporate code from
Bloodhound, then it would be released (as a whole) under the BSD license
with portions under the ALv2.

The licenses are bidirectionally compatible. You *cannot* "relicense" (as
I've seen mentioned else-thread) any of the code. You must distribute it
under the terms of its existing license, but those terms are extremely
liberal for both licenses.

But you're right, this might prove painful and could have been avoided
> had they stuck to the same license as ours. For example, some people
> pick only our wonderful plugin system in trac/core.py and a few other
> files, other pick some of our utilities. So far it's simple for them,
> we're a BSD project compatible with almost everything. What if now
> they have to carefully look if what they take is BSD, BSD + ALv2 or
> ALv2 only? Not impossible but harder than it is now. Of course, *we*
>
Well, the ALv2 is philosophically just like BSD, so this isn't a
complicated decision for consumers of a Trac (w/ Bloodhound code) release.
The material difference is that the ALv2 has been modernized in its
reference to copyright, trademark, and patent law. I can provide details if
anybody is curious, but I think that is mostly immaterial to the discussion
at hand. Suffice to say, the two licenses operate mostly the same, and are
fully-aligned in their permission philosophy.

But the first sentence is the sticking point for the ASF, as code developed
and released by the ASF must fall under the ALv2. We don't have a choice on
that point.


> could switch to ALv2, but such a move is hard to justify beforehand,
> and I think it will only happen if there's a really compelling reason
> to do so.
>
Your users would get the same style of license, so it wouldn't be a big
deal from their standpoint. But it is certainly some work for you.


> Besides, even if the license would be the same, another concern is the
> Apache policy related to contributor license agreements. I now wonder
> if the Bloodhound project will even able to integrate our changes back
> into their contributed and modified files (in a kind of "regularly
> merge from upstream" workflow), as the changes contributed to Trac
>
The CLA that Apache committers sign says they have the "right" to commit
the patch to version control. Whether that right is based on those provided
by the BSD license, or that the committer has authored their own work...
they can still make the commit.

In short: the ASF won't have any problems carrying upstream changes into
its codebase.

>...

I've rejiggered the subject line for this message to call out the licensing
stuff. I'd be more than happy to followup with any questions or concerns
that people may have. For reasons good or bad, I happen to know all too
much about this stuff :-P

Cheers,
-g

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/trac-dev/-/tPk7fKAY3gIJ.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2012-01-03 07:33:17 UTC
Permalink
On 1/3/2012 2:02 AM, Greg Stein wrote:
> On Monday, January 2, 2012 6:03:05 PM UTC-5, Christian Boos wrote:
> Besides, even if the license would be the same, another concern
is the
> Apache policy related to contributor license agreements. I now wonder
> if the Bloodhound project will even able to integrate our changes
back
> into their contributed and modified files (in a kind of "regularly
> merge from upstream" workflow), as the changes contributed to Trac
>
> The CLA that Apache committers sign says they have the "right" to commit
> the patch to version control. Whether that right is based on those
> provided by the BSD license, or that the committer has authored their
> own work... they can still make the commit.
>
> In short: the ASF won't have any problems carrying upstream changes into
> its codebase.
>

My question also covered Trac modifications to ALv2-only
files (i.e. those originally contributed by Bloodhound). Will
they also be integrated back? I fear not, otherwise that would
provide an easy way around the CLA which is mandatory on the
Apache side.

-- Christian

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
osimons
2011-12-31 00:13:37 UTC
Permalink
On Dec 30, 11:14 pm, Ethan Jucovy <***@gmail.com> wrote:
> I've posted a response to the proposal on the Apache Incubator list:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbo...
>
> As I said earlier in this thread, I'm all for more Trac distributions, but
> between the significant unresolved questions about community interactions,
> license compatibilities, and how to ensure this project remains symbiotic
> with Trac; the proposal's misrepresentations about the Trac community's
> procedures; and the lack of any clear, specific statements to date as to
> why Bloodhound must resort to a fork, I think this project would be much
> more likely to succeed and to have a healthy relationship with Trac if
> these issues are addressed before it moves forward.

Wow Ethan. I'm in awe. Really.

I had the Bloodhound discussion @ incubator mailing list bookmarked so
whenever I revisited I found no new posts. I figured the Apache
Incubator discussion had died down for the holiday, and would pick up
in the new year. I did not notice the pager appearing in the archives
at some stage (how dumb can users be!), so the mails with votes +
result on page 2 was unseen by me when I wrote the "uncertainty post"
that sparked this new round of discussion. If I had seen it, I may not
have posted figuring this was over-and-done with. I am glad I did
write, as this thread certainly is a testament to the interest that
Trac still has in the community.

Your summary is extremely accurate and well-documented. There is one
minor "OR" that need not be in there: As to my knowledge none of the
private communication included demands for Trac commit privileges.
Taking Trac to Apache was a hard requirement from the start, and at no
point did WANdisco express any interest in working with the Trac
community in its current form. Either move us, or replace/duplicate
us.

I hope the Apache Incubator & Bloodhound uses this information to
build a better project. Now that they have given life, I certainly
hope they can make the effort to spread some meat onto its thin
bones...


:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com


--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ian Wild
2011-12-31 02:16:53 UTC
Permalink
On Sat, Dec 31, 2011 at 12:13 AM, osimons <***@gmail.com> wrote:

> Your summary is extremely accurate and well-documented. There is one
> minor "OR" that need not be in there: As to my knowledge none of the
> private communication included demands for Trac commit privileges.
> Taking Trac to Apache was a hard requirement from the start, and at* no
> point did WANdisco express any interest in working with the Trac
> community in its current form. Either move us, or replace/duplicate
> us.*
>

That is inaccurate.

Our first discussions involved the active Trac committers along with many
others previously involved in the project. Our goal was to sponsor as many
full time developers as possible to work on the existing Trac project and
build something significantly more substantial in terms of appeal and
functionality. It was not until later that we were made aware of the
current status of Edgewall as a shell company with no employees and no
revenue. It was then we highlighted that for the level of investment we are
making we would need proper governance and infrastructure in place to
support the project. Suggesting the use of an opensource Software
foundation wasn't immediate and was not the only option, although it does
have many merits[1] that made it appealing.

If Ohloh[2] is to be believed, in the last 12 months the number of
committers contributing more than single digit number of changes to Trac
has been three, with the vast majority of the commits being entered by
Christian or Remy. That may hide other contributions, but the fact remains
that Trac as a project needs a head of steam if it is to get to a position
where it could become recognized as a leading issue tracker again. Perhaps
that goal isn't shared by everyone here, which is fine, but that's
certainly what Apache Bloodhound is aiming to do.

Unfortunately, no one from the initial group we contacted was able to
commit to working on Trac full time (or even part time afaik). Since then
we have been able to employ a number of experienced Python developers who
are familiar with the Trac architecture and who will be dedicated to the
project. I can assure people that the view so far is very much in favour of
maintaining compatibility with Trac and even the idea of forking or not is
certainly still open to discussion within the Apache Bloodhound community.

I truly hope none of this has to degenerate into a slanging match. I
believe our goals are broadly aligned and I'll state again that we aren't
here to undermine the Trac community of today and I simply don't believe we
will. The existing approach and ethos has value and there is no reason
anything has to change here if you guys don't want it to. I'm really happy
to be involved in this discussion and I think we can address all of the
points made if they haven't been already (It seems questions like licensing
have been, even if some people missed those answers). Given the public
Apache Bloodhound mailing list is to be launched very shortly, I think most
of my input into the discussion of the plans will be best made there and of
course anyone is welcome to participate in that too.

Best Wishes,

Ian

[1]
http://dirkriehle.com/publications/2010-2/the-economic-case-for-open-source-foundations/
[2] http://www.ohloh.net/p/trac/analyses/latest

--
Ian Wild
Director of Engineering
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>

Subversion community
http://www.svnforum.org

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Dirk Stöcker
2011-12-31 12:55:29 UTC
Permalink
On Sat, 31 Dec 2011, Ian Wild wrote:

> If Ohloh[2] is to be believed, in the last 12 months the number of committers contributing more than single digit number of changes to Trac has been three, with the vast majority of the commits being
> entered by Christian or Remy. That may hide other contributions, but the fact remains that Trac as a project needs a head of steam if it is to get to a position where it could become recognized as a
> leading issue tracker again. Perhaps that goal isn't shared by everyone here, which is fine, but that's certainly what Apache Bloodhound is aiming to do.  

My main project JOSM has about 5 active SVN contributors at the moment and
2 of them beeing administrators. These numbers are not much higher, but
JOSM is a fast evolving software tool with an equal structure like Trac: A
core and lots of plugins. Like for Trac the plugins are a major factor in
the acceptance of the tool and allow independent development.

We restrict SVN access to people which have proven their qualification by
sending bug reports and patches to the bug tracker (Trac of course). They
get SVN access as soon as I think they match the project standards. From
what I know Trac uses the same approach. I had no trouble to get the
permissions needed for my work at the spamfilter.

So to push Trac forward you simply would need to fix bugs and attach
high quality patches to Trac tickets. You would get SVN access soon. For
JOSM there have been people who got SVN after 1-2 weeks as they flooded
the bug tracker with fixes (actually this is also the way I got
maintainer of this software).

And/or you write plugins to extend functionality.

Google ATM finds "19.000" pages which are very likely Trac installations,
I don't see that Trac has a problem beeing "a leading issue tracker".
See "Search Google" at "http://trac.edgewall.org/wiki/TracUsers".

> Unfortunately, no one from the initial group we contacted was able to commit to working on Trac full time (or even part time afaik). Since then we have been able to employ a number of experienced Python
> developers who are familiar with the Trac architecture and who will be dedicated to the project. I can assure people that the view so far is very much in favour of maintaining compatibility with Trac and
> even the idea of forking or not is certainly still open to discussion within the Apache Bloodhound community.  

I compare this request now with my situation. Someone like your company is
asking to
* change the server infrastructure and control mechanisms
* change the license
* ask if core contributors will work for you full-time/part-time
for JOSM.

Actually my answer would be no for all of these requests. It took a long
time to establish running services, the code license is fine and I like
the job I have.

I don't see why Trac people should behave different.

> I truly hope none of this has to degenerate into a slanging match. I believe our goals are broadly aligned and I'll state again that we aren't here to undermine the Trac community of today and I simply
> don't believe we will.

Actually this is what I doubt. I'm in the OpenSource business for about 20
years and I have seen a lot of this. Forks sometimes are necessary and
healthy for a software. And I also see problems with Trac development
caused by little contribution, but actually I don't see that what you do
will make the situation better.

As said: If you could point to a long list of ignored patches,
improvements, hard discussions or other larger problems - the situation
would be much different.

But in the end I don't care. You have the right to do what you want to do,
so do it. If you can create a better product than Trac which is compatible
and does work with the dozens of extensions I made for my existing
installation, then I will happily switch. Otherwise I will stick to Trac
and continue to extend and improve it when necessary.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2012-01-02 21:03:58 UTC
Permalink
On 12/31/2011 1:55 PM, Dirk Stöcker wrote:
> On Sat, 31 Dec 2011, Ian Wild wrote:
>> Unfortunately, no one from the initial group we contacted was able to
>> commit to working on Trac full time (or even part time afaik). Since
>> then we have been able to employ a number of experienced Python
>> developers who are familiar with the Trac architecture and who will be
>> dedicated to the project. I can assure people that the view so far is
>> very much in favour of maintaining compatibility with Trac and
>> even the idea of forking or not is certainly still open to discussion
>> within the Apache Bloodhound community.
>
> I compare this request now with my situation. Someone like your company
> is asking to
> * change the server infrastructure and control mechanisms
> * change the license
> * ask if core contributors will work for you full-time/part-time
> for JOSM.
>
> Actually my answer would be no for all of these requests. It took a long
> time to establish running services, the code license is fine and I like
> the job I have.
>
> I don't see why Trac people should behave different.

Yes, that was exactly our situation and reaction as well.


> [...]
> But in the end I don't care. You have the right to do what you want to
> do, so do it. If you can create a better product than Trac which is
> compatible and does work with the dozens of extensions I made for my
> existing installation, then I will happily switch. Otherwise I will
> stick to Trac and continue to extend and improve it when necessary.
>

+1 ;-) We never frowned at anyone switching to Redmine for example, we
won't blame you for switching to Bloodhound if it becomes a better
alternative for you! (But if even in doing so, you could continue to
maintain the SpamFilterPlugin to its excellent level in a way that would
be compatible with the "legacy" Trac, all the better ;-) ).

-- Christian

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Hyrum K Wright
2011-12-31 19:45:24 UTC
Permalink
On Fri, Dec 30, 2011 at 8:16 PM, Ian Wild <***@wandisco.com> wrote:
> On Sat, Dec 31, 2011 at 12:13 AM, osimons <***@gmail.com> wrote:
>>
>> Your summary is extremely accurate and well-documented. There is one
>> minor "OR" that need not be in there: As to my knowledge none of the
>> private communication included demands for Trac commit privileges.
>> Taking Trac to Apache was a hard requirement from the start, and at no
>> point did WANdisco express any interest in working with the Trac
>> community in its current form. Either move us, or replace/duplicate
>> us.
>
>
> That is inaccurate.
>
> Our first discussions involved the active Trac committers along with many
> others previously involved in the project. Our goal was to sponsor as many
> full time developers as possible to work on the existing Trac project and
> build something significantly more substantial in terms of appeal and
> functionality. It was not until later that we were made aware of the current
> status of Edgewall as a shell company with no employees and no revenue. It
> was then we highlighted that for the level of investment we are making we
> would need proper governance and infrastructure in place to support the
> project. Suggesting the use of an opensource Software foundation wasn't
> immediate and was not the only option, although it does have many merits[1]
> that made it appealing.
>
> If Ohloh[2] is to be believed, in the last 12 months the number of
> committers contributing more than single digit number of changes to Trac has
> been three, with the vast majority of the commits being entered by Christian
> or Remy. That may hide other contributions, but the fact remains that Trac
> as a project needs a head of steam if it is to get to a position where it
> could become recognized as a leading issue tracker again. Perhaps that goal
> isn't shared by everyone here, which is fine, but that's certainly what
> Apache Bloodhound is aiming to do.
>
> Unfortunately, no one from the initial group we contacted was able to commit
> to working on Trac full time (or even part time afaik). Since then we have
> been able to employ a number of experienced Python developers who are
> familiar with the Trac architecture and who will be dedicated to the
> project. I can assure people that the view so far is very much in favour of
> maintaining compatibility with Trac and even the idea of forking or not is
> certainly still open to discussion within the Apache Bloodhound community.
>
> I truly hope none of this has to degenerate into a slanging match. I believe
> our goals are broadly aligned and I'll state again that we aren't here to
> undermine the Trac community of today and I simply don't believe we will.
> The existing approach and ethos has value and there is no reason anything
> has to change here if you guys don't want it to. I'm really happy to be
> involved in this discussion and I think we can address all of the points
> made if they haven't been already (It seems questions like licensing have
> been, even if some people missed those answers). Given the public Apache
> Bloodhound mailing list is to be launched very shortly, I think most of my
> input into the discussion of the plans will be best made there and of course
> anyone is welcome to participate in that too.

For what it's worth, the Bloodhound development list has been set up.
You can subscribe here:
bloodhound-dev-***@incubator.apache.org

The charter of that list is technical and project direction for
Bloodhound. Since much of the content in this thread is speculation
about what direction Bloodhound should take regarding compatibility
and such, I'd encourage that discussion to move over to the
Bloodhound-specific list.

Also, the next few days are holidays for a large part of the world.
Certainly discussions can happen whenever, but if the desire is to
encourage the most amount of participation, I'd recommend waiting a
few days before delving in too deep.

-Hyrum

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Steffen Hoffmann
2011-12-31 14:36:24 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 31.12.2011 01:13, wrote osimons:
> ... votes + result on page 2 was unseen by me when I wrote the
> "uncertainty post" that sparked this new round of discussion. If I
> had seen it, I may not have posted figuring this was over-and-done
> with. I am glad I did write, as this thread certainly is a testament
> to the interest that Trac still has in the community.

I've just caught-up with all the opinions mentioned within the last few
days. Many great and right-on-the-spot comments, thank you all for
sharing your thoughts.

Taking the successful vote for Bloodhound serious, I foresee a lot more
of my time going into communication next year. With the advent of the
upcoming Bloodhound project mailing list(s?) there will be another
resource to check for information and possibly to react upon.

It was doable for me to follow both trac-dev and th-users for the last
two years, but I fear my spare time could be not enough to follow yet
another list, especially when this is partially fed by full-time
developers. So if someone already monitoring the incubator mailing list
would throw in some pointers here as answers to Ethan's post appears
over there, I'll be grateful as in general for all Trac related pointers
and watch-out calls.

Happy New Year to everyone.

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

iEYEARECAAYFAk7/HeYACgkQ31DJeiZFuHddywCfYJSutzIwLqpb2FFXC7ITHnZd
9dkAoMj53RVLaJO8V8TwrS4/wfD3dLlB
=Fi8D
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Ethan Jucovy
2011-12-31 16:47:18 UTC
Permalink
On Sat, Dec 31, 2011 at 9:36 AM, Steffen Hoffmann <***@web.de> wrote:

> So if someone already monitoring the incubator mailing list
> would throw in some pointers here as answers to Ethan's post appears
> over there, I'll be grateful as in general for all Trac related pointers
> and watch-out calls.


I just received this reply:

"At this point, I would recommend that you hold a vote on the appropriate
Trac mailing list regarding approving or disapproving a fork and then
forwarding that here. If the existing community doesn't want a fork I
would suspect the incubator PMC would require the bloodhound project not to
start from one." (No link yet, the message hasn't shown up on the web
archives.)

I don't know if the Trac community has any formal procedure for a vote of
this nature but it seems that it might be useful to get opinions on record
here. To be clear, the point in question is not whether Bloodhound should
proceed but whether the existing Trac community would want that project not
to start from a fork.

I don't wish to drag out this conversation longer or more broadly than
necessary, but it seems enough of us have spoken up with concerns that I
suppose it's worth this last step. I'll start a thread about that.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2011-12-26 22:05:08 UTC
Permalink
On 12/25/2011 4:32 PM, Steffen Hoffmann wrote:
> When facing the growing Trac functionality and the current amount of
> plugins at trac-hacks.org and elsewhere, the call for better overview,
> easier plugin selection (get best plugin for given task) and convenient
> feature-enriched packages for better 1st-time user experience is only
> consequent.

It's perhaps also the right time to make a short list of plugins that
could be bundled to the core in some form or another. Bloodhound will
probably deliver a wider set of plugins than us, but even for the "core"
Trac distribution I think it would be good to integrate more default
optional components. For example take the XmlRpcPlugin, it's heavily
tied to what the Trac API delivers, it is already maintained by a Trac
developer and we already discussed that both Trac and that plugin could
benefit from some refactoring to share more code [1]. That would be one
of the candidates. The GitPlugin would be another, etc.

> [...]
> There is a saying: 'You know me by my actions, not by my words'. Among
> other things it had been announced by Wandisco representatives, that
> current (trac-hacks) developers and plugin maintainers would be
> contacted to speak about possible ways of collaboration. While I felt
> like this would qualify me at least for AccountManagerPlugin and
> TagsPlugin, I've heard nothing by now.

Well, the AccountManagerPlugin and TagsPlugin are also popular ones that
could get bundled in some form or another.

> If you don't see my point here, just one more thought: Today
> professional, key-turn application roll-outs are often virtual machines
> in cluster setups. How could we encourage wider Trac adoption more
> economic and sustainable within tight resource constraints, if not by
> working closely with OS vendors? I don't see, that anyone here goes into
> building images for VMware, VirtualBox, Xen& Co.

What about http://bitnami.org/stack/trac ?

> [...]
> I heartily welcome new developers joining here. Familiarize with the
> Trac ecosystem, become a part of it. You'll be respected and encouraged
> to take responsibility according to quantity and quality of
> contributions as I witnessed several times by now. Having sponsors to
> donate paid developer time could even yield a leap-frog progress at some
> issues.

Indeed. Until the Bloodhound mailing lists are created at the incubator,
and why not, even after that point, it would be good that Bloodhound
developers join the open discussion here in trac-***@googlegroups.com.
Also, it would be nice to announce the creation of those mailing lists
here, so that interested parties could also join the discussions that
will take place there.

>
> OTOH a diversion won't be good for any of the involved parties. Trac
> (plugin) developer base could be finally drained below the critical mass
> to do both, maintain existing solutions and produce remarkable, valuable new stuff

That's indeed a risk. As osimons reminded us, there's already quite some
maintenance work needed to have a plugin supported across several Trac
major versions. Ideally Bloodhound and Trac should retain some level of
compatibility. The big question is: do they intend to "fork and forget"
i.e. copy the code at some stable point (0.12.3? 0.13?) and then forget
about t.e.o's version of Trac and only focus on their own code, or to
the opposite, keep the changes from "upstream" flowing in and regularly
merge from t.e.o? I think the latter option makes the most sense and
will help to preserve a good level of compatibility.

> Just for getting the fame of Trac and respect of the
> community for this project into the Apache domain? I hope this isn't the
> hidden meaning of the Bloodhound proposal, and most probably it won't
> work out in the end anyway.
>

Certainly not. I think Apache doesn't need or care to get the Trac
"fame" and on our side we're not so interested in being covered by the
Apache "brand" either. There's no hidden meaning to the Bloodhound fork,
it's really just WANdisco wanting to do some business with Trac as a
starting point. As opposed to other companies who do the same, they want
to do it publicly as open source and they settled on Apache to host
their effort. This gives us the opportunity to have a look on what
they're doing and to take things back if we happen to find their changes
interesting. In that respect, it's a bit more interesting than if they
kept their changes private. The downside is the risk of fragmentation,
but I think it can be handled with appropriate communication between the
interested parties.

-- Christian

[1] - http://trac.edgewall.org/ticket/10125#comment:15

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Manuel Jesús Recena Soto
2011-12-26 23:20:10 UTC
Permalink
Hi,

2011/12/26 Christian Boos <***@free.fr>:
> On 12/25/2011 4:32 PM, Steffen Hoffmann wrote:
>>
>> When facing the growing Trac functionality and the current amount of
>> plugins at trac-hacks.org and elsewhere, the call for better overview,
>> easier plugin selection (get best plugin for given task) and convenient
>> feature-enriched packages for better 1st-time user experience is only
>> consequent.
>
>
> It's perhaps also the right time to make a short list of plugins that could
> be bundled to the core in some form or another. Bloodhound will probably
> deliver a wider set of plugins than us, but even for the "core" Trac
> distribution I think it would be good to integrate more default optional
> components. For example take the XmlRpcPlugin, it's heavily tied to what the
> Trac API delivers, it is already maintained by a Trac developer and we
> already discussed that both Trac and that plugin could benefit from some
> refactoring to share more code [1]. That would be one of the candidates. The
> GitPlugin would be another, etc.
>
>> [...]
>> There is a saying: 'You know me by my actions, not by my words'. Among
>> other things it had been announced by Wandisco representatives, that
>> current (trac-hacks) developers and plugin maintainers would be
>> contacted to speak about possible ways of collaboration. While I felt
>> like this would qualify me at least for AccountManagerPlugin and
>> TagsPlugin, I've heard nothing by now.
>
>
> Well, the AccountManagerPlugin and TagsPlugin are also popular ones that
> could get bundled in some form or another.
>
>> If you don't see my point here, just one more thought: Today
>> professional, key-turn application roll-outs are often virtual machines
>> in cluster setups. How could we encourage wider Trac adoption more
>> economic and sustainable within tight resource constraints, if not by
>> working closely with OS vendors? I don't see, that anyone here goes into
>> building images for VMware, VirtualBox, Xen&  Co.
>
>
> What about http://bitnami.org/stack/trac ?

A note, also we have Clinker Virtual Appliance [1] with Subversion,
Trac, Nexus, Sonar and Jenkins.
There is also Clinker Cloud [2].

[1] http://clinkerhq.com/products#va
[2] http://clinkerhq.com/products#cloud

>
>> [...]
>> I heartily welcome new developers joining here. Familiarize with the
>> Trac ecosystem, become a part of it. You'll be respected and encouraged
>> to take responsibility according to quantity and quality of
>> contributions as I witnessed several times by now. Having sponsors to
>> donate paid developer time could even yield a leap-frog progress at some
>> issues.
>
>
> Indeed. Until the Bloodhound mailing lists are created at the incubator, and
> why not, even after that point, it would be good that Bloodhound developers
> join the open discussion here in trac-***@googlegroups.com. Also, it would
> be nice to announce the creation of those mailing lists here, so that
> interested parties could also join the discussions that will take place
> there.
>
>>
>> OTOH a diversion won't be good for any of the involved parties. Trac
>> (plugin) developer base could be finally drained below the critical mass
>> to do both, maintain existing solutions and produce remarkable, valuable
>> new stuff
>
>
> That's indeed a risk. As osimons reminded us, there's already quite some
> maintenance work needed to have a plugin supported across several Trac major
> versions. Ideally Bloodhound and Trac should retain some level of
> compatibility. The big question is: do they intend to "fork and forget" i.e.
> copy the code at some stable point (0.12.3? 0.13?) and then forget about
> t.e.o's version of Trac and only focus on their own code, or to the
> opposite, keep the changes from "upstream" flowing in and regularly merge
> from t.e.o? I think the latter option makes the most sense and will help to
> preserve a good level of compatibility.
>
>> Just for getting the fame of Trac and respect of the
>> community for this project into the Apache domain? I hope this isn't the
>> hidden meaning of the Bloodhound proposal, and most probably it won't
>> work out in the end anyway.
>>
>
> Certainly not. I think Apache doesn't need or care to get the Trac "fame"
> and on our side we're not so interested in being covered by the Apache
> "brand" either. There's no hidden meaning to the Bloodhound fork, it's
> really just WANdisco wanting to do some business with Trac as a starting
> point. As opposed to other companies who do the same, they want to do it
> publicly as open source and they settled on Apache to host their effort.
> This gives us the opportunity to have a look on what they're doing and to
> take things back if we happen to find their changes interesting. In that
> respect, it's a bit more interesting than if they kept their changes
> private. The downside is the risk of fragmentation, but I think it can be
> handled with appropriate communication between the interested parties.
>
> -- Christian

Regards,

>
> [1] - http://trac.edgewall.org/ticket/10125#comment:15
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-***@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+***@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>



--
Manuel J. Recena Soto
* www.manuelrecena.com[/blog]
* www.linkedin.com/in/recena
* ***@gmail.com
* +34 609710280 (ES)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Olemis Lang
2011-12-27 18:04:08 UTC
Permalink
I found Odd Simons (and other people ;)'s comments very interesting so here
you have my own $0.02 version . Firstly I say that I enjoy when people say
to me things like <<you're so damn wrong that it hurts>> , so please don't
hesitate to do so if you feel it's necessary . I write this by assuming
I'm terribly wrong and consult my personal psycho because I have butterflies
inside my head ;) .

Secondly , there are a few facts involved in this story :

- Wandisco has decided to launch some services and products. As a consequence
  a decision has been made that Trac should/will be the starting point to
  achieve product/service goals .
  * This means that continued and stable product support, defect resolution,
    ... are needed so as to ensure quality, reliability, ... and (I'm guessing)
    commitment so as to obtain some return-on-investment considering resources
    planned to be dedicated to this effort .
  * For some reason the current state of Trac community does not satisfy
    these requirements (... and honestly I understand this position ; e.g.
    the fact that Trac-Hacks is still running 0.10 , XML-RPC is
    disabled , etc, and nothing can be done even if some people want to, that's
    a bit frustrating for me - and this is not to blame anybody in particular,
    that's a fact and just an example - )
- The initial offer sent by the company to trac-dev & trac-users MLs was not
  received as they expected (for further details please consult previous
  comments).
- For some reasons (previous experience, ... whatever) ASF alignment seems to
  be a very important (non-technical?) decision

The fact that Wandisco still wants to consider Trac as the starting point to
achieve some goals (disregarding the other details involved) is positive
AFAICT . The fork of the project is, in part, a consequence of
aforementioned conflict of interests . The duplicate effort and overhead will
follow, but there are some technical and non-technical decisions that might
mitigate the impact on both projects ; as long as they both will be able
«coexist peacefully» (<= I hope you understand what I mean ) so that
maybe maintaining plugins for Bloodhound &
Trac will be similar to maintaining Trac plugins for 0.10 , 0.11 , 0.12 & 0.13 .

I do believe that it would be very important if both projects are in synch and
consider compatibilty as a goal to survive in this cruel world . Maybe a clear
workflow (policy , ... or whatever name you want to use ;) to exchange code
back and forth might help. I don't know what will happen in a near future but
there's still a chance to make this happen just like many other software
hosted by social coding sites (e.g. Bitbucket, Github ...) where many users
(in this case Wandisco , Trac-dev community , maybe others later ... who knows?)
commit changes to their (personal) repositories or patch queue repository and
notify each other (e.g. by sending push/pull requests, patches under version
control, ... whatever) of changes for review, approval, etc . Apache vs BSD
should not be a problem .

Another fact is that some plugin developers (please add my name to the list)
have no chance to dedicate time to develop Trac plugins . Myself , I have a
very long TODO list of enhancements , and I have not developed anything
related to Trac since long time ago, even if I'd liked to, because I really
cannot dedicate time to this (ok ... shame on me). The offer to
support full-time Trac/Bloodhound developers IMO is positive as well AFAICS .
I hope you agree if I mention that there's still a lot of place for enhancement
in Trac core and plugins , e.g. testing and related QA, OS-specific packaging
and more.

AFAICS (and I may be wrong) this is happening nowadays in many
open-source projects, even if **circumstances are not always the same** . I'll
mention some of them :

- Mercurial is a well established FLOSS project ... there you have Google
  maintaining a custom branch of development to make it run on top of their
  Big Table & Co. infraestructure.
- Subversion is another paradigmatic FLOSS project . Once again there you have
  many companies building cutomized Subversion distributions (including
  Google & Wandisco) and paying developers (including Google & Wandisco) to
  make the project move forward .
- Trac itself has been customized , patched , packaged & distributed in many
  forms ... e.g. Bitnami , OForge , Sourceforge as a hosted app , Assembla ...
  and project is still alive (although this is a completely different story).
- Ubuntu & Debian ... a love story ;)
- The Linux kernel vs patched kernels (e.g. Red Hat's ? , SuSE's ?)
- OTOH other projects e.g. Hudson have been forked (e.g. Jenkins) and both of
  them survive and were able (as far as I could see in the ML ...) to
  <<move the wheel together>> while still keeping their own identity.

Well I really cannot dedicate more time to write .
I look forward to your comments as well , hoping this initiative will
be positive for
both Trac & Bloodhound

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw

Featured article : Personalizando imagenes mostradas al compartir
páginas en sitios sociales
http://feedproxy.google.com/~r/simelo-news/~3/nSdht_RqLKk/personalizando-imagenes-mostradas-al.html
Tweet: +1 RT @holdenweb This is insane. Everyone should be fighting
this: Stop American Censorship http://t.co/S9EIkYdk #fb
Follow @olemislc Reply Retweet   23:08 Dec-14
  Get this email app!
Get a signature like this. CLICK HERE.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
anatoly techtonik
2011-12-28 09:25:43 UTC
Permalink
There is an opinion that WANdisco tries to gain market share by pretending
they are the major driving force behind the open source communities that
support projects like Subversion and Trac. But in case of Trac the
marketing efforts can be wasted, because IIUC none of WANdisco employers
have a trail of commits to Trac core. So, the best way to build up a
"reputation" is to place WANdisco members name on the official page of
Apache Software Foundation with Trac and Apache logos and a new project
name announcement. And then include this new project name in all marketing
materials.

The strategy that hurts an ecosystem.

Nothing prevents WANdisco from contributing back to Trac, but they didn't
and probably don't want to, so I believe the true motives are somewhat
different from the goals of community.

Somebody said that there is no time to review changes from Wd members. This
problem can be solved without Apache projects and all that buzz. First, Wd
can stash the changes much like everyone else does and just remove them
from their own branch when the changes are merged. It's just a matter of
coding culture and maturity of company processes to be able to do so.
Second, it could speed up the review process by compensating time of Trac
core developers without buying and restricting them to be a flag bearers of
Wd. There is a legal entity - Edgewall Software, that's year after year
supported this project (unlike Wd), so nobody would really object if you
could try to cooperate with them first instead of jumping into your own
public project and calling for everyone to move.
--
anatoly t.

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Felix Schwarz
2011-12-28 11:28:43 UTC
Permalink
Am 28.12.2011 10:25, schrieb anatoly techtonik:
> There is an opinion that WANdisco tries to gain market share by pretending
> they are the major driving force behind the open source communities that
> support projects like Subversion and Trac. But in case of Trac the marketing
> efforts can be wasted, because IIUC none of WANdisco employers have a trail of
> commits to Trac core. So, the best way to build up a "reputation" is to place
> WANdisco members name on the official page of Apache Software Foundation with
> Trac and Apache logos and a new project name announcement. And then include
> this new project name in all marketing materials.
>
> The strategy that hurts an ecosystem.

Sorry but I think that this conclusion is unfounded and does WANdisco wrong.
From my talks with them I have the impression that they really like to drive
an open source trac forward.

Also there is at least Mat Booth which has a bit of Trac experience.

> Somebody said that there is no time to review changes from Wd members.

That was cboos+rblank, the two most knowlegable Trac developers. I guess we
should trust them with the assessment.

> There is a legal
> entity - Edgewall Software, that's year after year supported this project
> (unlike Wd),

Is Edgewall still operating? My impression is that it is inactive and all Trac
developers are employed by other companies/self-employed. Also you can't
seriously compare the Apache Foundation with a tiny company.

And last but not least it's not only about a legal entity but also about
Apache being a foundation which won't turn around and leave which is possible
for any commercial entity.

In the end I have to say that your post is unfounded and partly unfair to
WANdisco - probably it just came around the wrong way due to the nature of email.

fs

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Dirk Stöcker
2011-12-28 14:32:39 UTC
Permalink
On Wed, 28 Dec 2011, Felix Schwarz wrote:

> On 28.12.2011 10:25, Anatoly Techtonik wrote:
>> There is an opinion that WANdisco tries to gain market share by pretending
>> they are the major driving force behind the open source communities that
>> support projects like Subversion and Trac. But in case of Trac the marketing
>> efforts can be wasted, because IIUC none of WANdisco employers have a trail of
>> commits to Trac core. So, the best way to build up a "reputation" is to place
>> WANdisco members name on the official page of Apache Software Foundation with
>> Trac and Apache logos and a new project name announcement. And then include
>> this new project name in all marketing materials.
>>
>> The strategy that hurts an ecosystem.
>
> Sorry but I think that this conclusion is unfounded and does WANdisco wrong.
>> From my talks with them I have the impression that they really like to drive
> an open source trac forward.
>
> Also there is at least Mat Booth which has a bit of Trac experience.
>
>> Somebody said that there is no time to review changes from Wd members.
>
> That was cboos+rblank, the two most knowlegable Trac developers. I guess we
> should trust them with the assessment.

I'm not the big Trac developer, as Trac is only a tool I need to manage my
current main software, but still I agree with Anatoly, that the way it is
presented currently seems strange to me.

If WANdisco would have done major changes and improvements or even lots of
ticket fixes and the patches would have been ignored for a long time, then
I would agree something is wrong and a fork probably necessary.

But although I'm not really happy with the progress of Trac I can't blame
Trac maintainers for ignoring patches. They ignore bug reports (a logical
effect due to missing resources), but the don't ignore provided help.

So I doubt the motives of a fork are really positive.

The proper way would be to participate and help driving Trac into future.
When during this process development is moved to other servers and
maintaining is done mainly by WANdisco then this seems fine to me.

> Is Edgewall still operating? My impression is that it is inactive and all Trac
> developers are employed by other companies/self-employed. Also you can't
> seriously compare the Apache Foundation with a tiny company.
>
> And last but not least it's not only about a legal entity but also about
> Apache being a foundation which won't turn around and leave which is possible
> for any commercial entity.

Actually I don't understand why "company" should be better. I do both
commercial software development and open source and most of the time the
open source projects (when at least minimal successful) have much higher
quality than everything commercials are able to produce. Software
development does not need a company behind. The last 20 years showed this
clearly.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2011-12-28 18:34:21 UTC
Permalink
Hello Anatoly,

While I can understand your concerns, hostility will bring us nowhere,
so please try to keep an open mind ;-)

On 12/28/2011 10:25 AM, anatoly techtonik wrote:
> There is an opinion that WANdisco tries to gain market share by
> pretending they are the major driving force behind the open source
> communities that support projects like Subversion and Trac.

They indeed are one of the major contributors for Subversion (sponsoring
Greg and employing Hyrum, AFAIK).

> But in case
> of Trac the marketing efforts can be wasted, because IIUC none of
> WANdisco employers have a trail of commits to Trac core. So, the best
> way to build up a "reputation" is to place WANdisco members name on the
> official page of Apache Software Foundation with Trac and Apache logos
> and a new project name announcement. And then include this new project
> name in all marketing materials.
>
> The strategy that hurts an ecosystem.
>
> Nothing prevents WANdisco from contributing back to Trac, but they
> didn't and probably don't want to, so I believe the true motives are
> somewhat different from the goals of community.

Well, they made their true motive clear enough, no need to search for an
hidden agenda. They want to try to build a JIRA competitor and selected
Trac as the starting point, then hope that having one or two full time
paid developers plus an emerging Apache-based community will do the
rest. There's of course no guarantee that this strategy will work (and
during the first "private" rounds of discussion I think I did my best to
draw their attention to the various risks this implied), but they
nevertheless want to try it out, so let's just hope we can get a
positive outcome from this initiative. I imagine that at the very least
those full-time developers will manage to produce some interesting
changes that we, hobbyist developers, could learn from ;-) And then
maybe not, we'll see.

>
> Somebody said that there is no time to review changes from Wd members.
> This problem can be solved without Apache projects and all that buzz.
> First, Wd can stash the changes much like everyone else does and just
> remove them from their own branch when the changes are merged. It's just
> a matter of coding culture and maturity of company processes to be able
> to do so.

Remember that they're Subversion proponents, so the fork/merge mentality
of DVCs is not exactly part of their culture [1], which I find curious
because it's just a natural extension to the "don't be afraid of
conflicts" motto inherited from CVS [2] (but I digress...)

> Second, it could speed up the review process by compensating
> time of Trac core developers without buying and restricting them to be a
> flag bearers of Wd. There is a legal entity - Edgewall Software, that's
> year after year supported this project (unlike Wd), so nobody would
> really object if you could try to cooperate with them first instead of
> jumping into your own public project and calling for everyone to move.

This didn't work out for various reasons, and no matter how you look at
it, it's hard to imagine that any kind of sponsorship / compensation
would go without influencing the technical decisions we could make (e.g.
what if we were wanting to put svn and git at the same support level as
optional components under tracopt?).

-- Christian

[1] http://blogs.wandisco.com/2008/07/17/what-a-git/
[2]
http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Christian Boos
2011-12-26 00:01:25 UTC
Permalink
Hello

Simon, I hope you won't mind me quoting only the last bit of your mail,
it contains many other interesting points and I'll probably have a
second answer to elaborate on other aspects of it, but I'd like to first
clear a misconception that I've found in the last paragraph of your mail.

On 12/25/2011 4:14 AM, osimons wrote:
> I really wish the efforts were joined at the hip for now, and I'd have
> no reason to feel uncertain about a fork if there were months of
> preceding argument about project direction here at trac-dev. I would
> be blatantly obvious that a fork was needed, costing what it may.
> However, it is my firm belief that a software fork born out of
> critical discussion between people that disagree, will be of much
> better quality than a fork largely built by consensus in the offices
> of a corporate sponsor.
>

That's not exactly how it happened. Rather, "we" (cboos, rblank, jonas)
suggested the fork as the best way to get things moving forward for
WANdisco. Back in April (2011), they were talking about committing one
or two full-time developers to Trac, and as Remy and me got less an less
time for the project (as everyone could see), we were simply afraid that
our limited capacity of reviewing would be a bottleneck for them. Ok,
considering the very limited amount of contributions they produced so
far, our fears may now seem exaggerated ;-) Anyway, this could still
happen, as they're possibly still into an exploratory phase where
nothing from their side is yet public, so the model still holds: from
our point of view, their fork is potentially just an "external branch"
where they can evolve at their own speed and that we will try to review
at our pace and reintegrate whenever it makes sense. So why an external
branch, and not just a "sandbox" branch, you may ask? This indeed has to
do with politics and David Richards from WANdisco made it quite clear
early on that he was a bit concerned with the somewhat fuzzy status of
Edgewall and that he was much more comfortable sponsoring work under the
umbrella of Apache (so mostly for trademarks and IP concerns, IIUC).
From our side, we felt more comfortable to stick with the informal
Edgewall ways rather than switching to the more bureaucratic Apache
ways. Redoing the work on the infrastructure was not something
especially appealing either, given that after years of patient work we
finally reached a quite satisfying state. And again, before deciding a
move, we wanted to be sure it would be worth it and for that we needed
to "see" something happen.

So the way Ian explained what happened was indeed quite accurate:

On Dec 2, 1:41 pm, Ian Wild <***@wandisco.com> wrote:
>> As some of you may already be aware, earlier this year WANdisco[1]
>> approached members of the Trac development community with a view to working
>> out how we could most effectively invest development time into the project.
>> ...
>> The resulting discussions were interesting and culminated in the idea that
>> we might get the most done in the shortest time by performing a 'friendly
>> fork' of Trac and running that as a separate FOSS project. It was felt this
>> would present the least risk for everyone involved while still leaving
>> options open for future collaboration.

However we didn't say they should start with incubating an Apache
project. That was their call, and at this level I somehow share the
concerns about the risks of possible fragmentation of the community.
Starting with a new project like that may send the signal that they're
taking the Trac code base as it stands today and taking it somewhere
else (where? "as the community says"; but as there's not yet a community
for Bloodhound, there seem to be a bootstrapping issue there ;-) ).

Also there seem to be some discrepancy between the following reassuring
statements from Ian:

>> I want to be clear that our intention is in no way to undermine the current
>> Trac project and the progress that is making. We hope there can be
>> mutual collaboration and a shared journey. This approach gives us both the
>> freedom to continue with our own strategies while allowing us all to stay
>> engaged with each other and to achieve what I'm sure all of us desire - To
>> make Trac the best defect tracker on the planet.

and the wording of the Bloodhound proposal, which rather indicate a
"take over" approach:

- in the "Rationale" [1]:
>>> the current Trac development community is small and reluctant to
accept outside contributions.

Opinions here could diverge, but IMHO that's blatantly wrong. As any
project we're reluctant to accept marginally useful features or
unfinished code, but there's no shortage of good patches and good
contributions from non-committers which have been integrated. Not to
mention this is a bit strong of a statement coming from a party which so
far proposed no code contributions.

And by the way, committer status on Edgewall is usually granted after
seeing enough actual good patches from the contributor and a
demonstrated interest to the project, not when someone says "hey, this
project looks remotely interesting to me, I have no idea if I can or
will contribute but count me in" (slight caricature of an actual
self-appointment as a Bloodhound committer, recently seen in
***@incubator.apache.org - any parallel with sOme Other Apache
incubator project would certainly be seen as a stretch ;-) ).

>>> Given the Foundation’s reputation for building and maintaining
communities, we feel a new project, based on Trac but incubated under
the Apache umbrella, would help re-build the developer community, jump
started by developer time donated by WANdisco

"Re-build the developer community" rather than participate, expand or
similar...

- in the "Community" [2]:
>>> The current developers and supporting institution have moved on to
other things, and this has caused stagnation in the existing community.

Grr... we're not yet dead, and... we'll be back! :-)


I think we could continue at length to discuss how things could or
should work out, but from my side I'll take a very pragmatic approach:
if I see good stuff on the Bloodhound side, I'll probably propose to
take it back in t.e.o; if there are simply too many good things coming
from their side, we will probably regularly integrate their code
wholesale or possibly even "join" Bloodhound at some point in the
future; if there's only little activity or things that we don't like, we
will just continue our business as usual...

Nothing that dramatic, there are much bigger issues to tackle, like the
fact that the Trac model is progressively being dragged into the margin
by the advent of the likes of Github, Bitbucket and other Google Code...

-- Christian

[1]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Rationale

[2]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Community

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Remy Blank
2011-12-26 00:26:15 UTC
Permalink
osimons wrote:
> The intention of this email was to describe my thoughts and
> uncertainty.

Let me start by saying that I share most of Simon's concerns and open
questions.

Let me also give some more history about how it all came to the current
state, from the perspective of a Trac developer. Christian was contacted
privately by WANdisco on April 12th, about integrating Trac into a new
product of theirs. I was CCd on Christian's reply, and have been
involved in the discussions since then, as have all active core Trac
developers, through e-mail and 1:1 phone calls.

The discussions remained private because that's how we were contacted,
and we did suggest moving them to more public channels, which was
finally done by Ian Wild on December 2nd. In retrospect, we should have
moved to trac-dev much earlier, but as usual, hindsight is 20/20.

From very early on, WANdisco has been pushing for moving the Trac
project to the Apache Software Foundation. It seems that they were
worried about the somewhat fuzzy relationship between Trac and Edgewall
Software, and feared that the latter could interfere at some point. They
also mentioned its being an advantage for building a strong community.
This push was so strong, it kind of eclipsed the technical discussion,
of which there was very little.

The discussion more or less died at the end of May, and we haven't heard
much until the announce of Bloodhound in December.


Now for the more subjective part. Like many open-source projects, Trac
has always considered contributions based on their technical merit. So
you can imagine that we were a bit suspicious when WANdisco came in,
talking big about future contributions, asked for moving the project to
a different guidance and infrastructure, and proposed to add massive
manpower to the project (and by massive, I mean "much more than what the
current core developers can devote to the project", which is, granted,
very little).

So we suggested putting the move to the ASF on hold for the moment, and
to review the question after a few months of collaboration. We also
suggested the "friendly fork" variant as a way to avoid being a
bottleneck for contributions, as both Christian and myself had (and
unfortunately still have) very little time to spend on Trac. That's
where the discussions stopped.

So WANdisco went ahead and submitted their proposal to the ASF as a
first step. I still find this quite a heavy first step, but I guess
there were good reasons for that. I had really meant "friendly fork"
rather as "clone the Mercurial or Git mirror" than "re-license, re-brand
and re-import the whole project into the central Apache repository", but
I guess there's not really that much of a difference.

About fragmenting the community, the move to the ASF seems to me like
having more risk than a more light-weight approach, but TBH I have too
little experience with open-source projects in general to judge. From a
purely technical perspective, I believe it will be difficult to keep
compatibility between Trac and Bloodhound from the plugin perspective
for long, unless it's a major priority of WANdisco. It's already
difficult to make a plugin compatible with several major Trac releases,
let alone with diverging codebases. So I suspect plugin authors will
have to either choose their platform, or maintain separate (diverging)
branches.

As for myself, well, I guess Ian's "wait and see" quite accurately
describes my current position. I suspect that I will be more at ease in
a purely fun-driven project than a project that is partially driven by
the need to make money for at least one major participant, but I'm open
to changing my mind. For the moment, it will be business as usual in
Trac. If anything can be brought back from Bloodhound into Trac, great.
If not, that's ok, too. What I'm not going to do is duplicate my
efforts, and I wonder how many plugin authors will have the same thought.

-- Remy
Andy Baker
2011-12-26 00:47:55 UTC
Permalink
Awesome. Stupidly I'd entirely not thought about the plugin side.

As brilliant as the Trac core is, it is just that; a core. It is,
forgive me, worthless in the real world without the plugins. I'm an
end user of the product but even the basic build recipe always has
half a dozen plugins delivered as standard.

Remy Blank wrote:
> .. For the moment, it will be business as usual in
> Trac. If anything can be brought back from Bloodhound into Trac, great.
> If not, that's ok, too. What I'm not going to do is duplicate my
> efforts, and I wonder how many plugin authors will have the same thought.

Hard to argue with that.


On 26 December 2011 00:26, Remy Blank <***@pobox.com> wrote:
> osimons wrote:
>> The intention of this email was to describe my thoughts and
>> uncertainty.
>
> Let me start by saying that I share most of Simon's concerns and open
> questions.
>
> Let me also give some more history about how it all came to the current
> state, from the perspective of a Trac developer. Christian was contacted
> privately by WANdisco on April 12th, about integrating Trac into a new
> product of theirs. I was CCd on Christian's reply, and have been
> involved in the discussions since then, as have all active core Trac
> developers, through e-mail and 1:1 phone calls.
>
> The discussions remained private because that's how we were contacted,
> and we did suggest moving them to more public channels, which was
> finally done by Ian Wild on December 2nd. In retrospect, we should have
> moved to trac-dev much earlier, but as usual, hindsight is 20/20.
>
> From very early on, WANdisco has been pushing for moving the Trac
> project to the Apache Software Foundation. It seems that they were
> worried about the somewhat fuzzy relationship between Trac and Edgewall
> Software, and feared that the latter could interfere at some point. They
> also mentioned its being an advantage for building a strong community.
> This push was so strong, it kind of eclipsed the technical discussion,
> of which there was very little.
>
> The discussion more or less died at the end of May, and we haven't heard
> much until the announce of Bloodhound in December.
>
>
> Now for the more subjective part. Like many open-source projects, Trac
> has always considered contributions based on their technical merit. So
> you can imagine that we were a bit suspicious when WANdisco came in,
> talking big about future contributions, asked for moving the project to
> a different guidance and infrastructure, and proposed to add massive
> manpower to the project (and by massive, I mean "much more than what the
> current core developers can devote to the project", which is, granted,
> very little).
>
> So we suggested putting the move to the ASF on hold for the moment, and
> to review the question after a few months of collaboration. We also
> suggested the "friendly fork" variant as a way to avoid being a
> bottleneck for contributions, as both Christian and myself had (and
> unfortunately still have) very little time to spend on Trac. That's
> where the discussions stopped.
>
> So WANdisco went ahead and submitted their proposal to the ASF as a
> first step. I still find this quite a heavy first step, but I guess
> there were good reasons for that. I had really meant "friendly fork"
> rather as "clone the Mercurial or Git mirror" than "re-license, re-brand
> and re-import the whole project into the central Apache repository", but
> I guess there's not really that much of a difference.
>
> About fragmenting the community, the move to the ASF seems to me like
> having more risk than a more light-weight approach, but TBH I have too
> little experience with open-source projects in general to judge. From a
> purely technical perspective, I believe it will be difficult to keep
> compatibility between Trac and Bloodhound from the plugin perspective
> for long, unless it's a major priority of WANdisco. It's already
> difficult to make a plugin compatible with several major Trac releases,
> let alone with diverging codebases. So I suspect plugin authors will
> have to either choose their platform, or maintain separate (diverging)
> branches.
>
> As for myself, well, I guess Ian's "wait and see" quite accurately
> describes my current position. I suspect that I will be more at ease in
> a purely fun-driven project than a project that is partially driven by
> the need to make money for at least one major participant, but I'm open
> to changing my mind. For the moment, it will be business as usual in
> Trac. If anything can be brought back from Bloodhound into Trac, great.
> If not, that's ok, too. What I'm not going to do is duplicate my
> efforts, and I wonder how many plugin authors will have the same thought.
>
> -- Remy
>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Greg Stein
2012-01-03 07:49:02 UTC
Permalink
On Jan 3, 2012 2:33 AM, "Christian Boos" <***@free.fr> wrote:
>
> On 1/3/2012 2:02 AM, Greg Stein wrote:
> > On Monday, January 2, 2012 6:03:05 PM UTC-5, Christian Boos wrote:
> > Besides, even if the license would be the same, another concern is
the
> > Apache policy related to contributor license agreements. I now
wonder
> > if the Bloodhound project will even able to integrate our changes
back
> > into their contributed and modified files (in a kind of "regularly
> > merge from upstream" workflow), as the changes contributed to Trac
> >
> > The CLA that Apache committers sign says they have the "right" to commit
> > the patch to version control. Whether that right is based on those
> > provided by the BSD license, or that the committer has authored their
> > own work... they can still make the commit.
> >
> > In short: the ASF won't have any problems carrying upstream changes into
> > its codebase.
> >
>
> My question also covered Trac modifications to ALv2-only
> files (i.e. those originally contributed by Bloodhound). Will
> they also be integrated back? I fear not, otherwise that would
> provide an easy way around the CLA which is mandatory on the
> Apache side.

You could make a reasonable argument that those modifications were made
under the ALv2 stamped on the file. Further, clause 5 of ALv2 could be
construed as applying to those modifications made to the ALv2 files living
in the Trac repository.

And remember: everything is upon the committer. They can *always* commit
fraud against the CLA they signed. They could be lifting code from inside a
company's private product. The ASF takes the signed CLA at face value, and
does not second guess. The committer must know they have the right to apply
the patch. I think that minor changes to an ALv2 file are easy. Large
changes... maybe a little extra work (a statement, or even better, a CLA)
would be prudent.

Should Trac coders worry about it? You could say, "not my problem; the
Bloodhound coders need to figure it out." You could also argue they should
for better cross-project improvement. Personal choice, I think.

Is it clean? Nope. Could it be better? Yup. Does it really matter in the
end? Probably not.

Intentions are important, but reality is only settled in a court, if it
comes to that. And a court will look very strongly at intent, rather than
just paperwork. And do we ever expect to be in a court? I sure hope not!
(fwiw, one purpose of the ASF is keeping committers out of court)

Cheers,
-g

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Loading...