New Trac based project
Ian Wild
Ian Wild
http://www.wandisco.com
http://www.wandisco.com/subversion
Subversion community
Ian Wild
Ian Wild
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.
Simon Cross
> 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
Ian Wild
* Is Bitten one of the plugins you're planning to include in Bloodhound?
* Do you envisage Bloodhound also forking Genshi?
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.
Ian Wild
http://www.wandisco.com
http://www.wandisco.com/subversion
Subversion community
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+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
Simon Cross
> 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.
Ed - 0x1b, Inc.
yup - what he said +1
I am interested in seeing/helping Trac become fully semantic web enabled.
Ed
Grzegorz Sobanski
> 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.
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
Ian Wild
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?
Olemis Lang
:)
On Thu, Dec 8, 2011 at 12:01 PM, Ian Wild <ian....@wandisco.com> wrote:
>
> On Thu, Dec 8, 2011 at 1:11 PM, Grzegorz Sobanski <si...@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.
Ian Wild
... 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 .
osimons
>
> 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
Steffen Hoffmann
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-----
Ethan Jucovy
Greg Troxel
Ethan Jucovy <ethan....@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
Ian Wild
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
http://www.wandisco.com/subversion
Subversion community
http://www.svnforum.org
Ian Wild
Cell : +44 (0)7961193722
Office DDI: +44 (0)114 3030472
http://www.wandisco.com
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.
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
Felix Schwarz
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
Andy Baker
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.
Ethan Jucovy
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.
Ian Wild
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.
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.
Andy Baker
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.
Ian Wild
Greg Troxel
Ian Wild <ian....@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.)
Christian Boos
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 <ian.w...@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
gen...@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
Andy Baker
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.
Andy Baker
anyone raised the agile42 thing?
Remy Blank
> 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
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.
Felix Schwarz
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
Benjamin Lau
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
Felix Schwarz
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
Christian Boos
> 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
Christian Boos
> 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
[2] http://www.apache.org/foundation/license-faq.html#Distribute-changes
Manuel Jesús Recena Soto
2011/12/26 Christian Boos <christi...@free.fr>:
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
Regards,
> --
> 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+u...@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
* rec...@gmail.com
* +34 609710280 (ES)
Olemis Lang
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.
anatoly techtonik
Felix Schwarz
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
Felix Schwarz
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
Dirk Stöcker
> 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)
Christian Boos
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
John Hampton
"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 ofthe 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").
Ethan Jucovy
Christian Boos
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_-mcE8uB0sp6...@mail.gmail.com%3E).
It will nevertheless be instructive to read the answers to your post.
-- Christian
Dirk Stöcker
> 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_-mcE8uB0sp6...@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).
osimons
> I've posted a response to the proposal on the Apache Incubator list:
>
> 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.
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
osimons
> On Sat, 31 Dec 2011, Christian Boos wrote:
> > Well, the vote was already closed the 22th of December and Bloodhound is now
> > "incubating"
> > 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).
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.
Ian Wild
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.
Ian Wild
http://www.wandisco.com
http://www.wandisco.com/subversion
Subversion community
DavidRichards
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
Felix Schwarz
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 :-)
Ian Wild
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 :-)
> 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
Dirk Stöcker
> 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.
Ian Wild
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.
Dirk Stöcker
> 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.
Ethan Jucovy
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'?
Dirk Stöcker
>> 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.
Steffen Hoffmann
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-----
Ethan Jucovy
So if someone already monitoring the incubator mailing listwould 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.
Hyrum K Wright
For what it's worth, the Bloodhound development list has been set up.
You can subscribe here:
bloodhound-d...@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
Christian Boos
> 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
Christian Boos
> 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
Greg Stein
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
Christian Boos
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
Greg Stein
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