On 19.04.2013 12:25, Gary Martin wrote: > On 18/04/13 13:58, Branko Čibej wrote: >> On 18.04.2013 14:38, Gary Martin wrote: >>> On 18/04/13 13:23, Ryan Ollos wrote: >>>> On Mon, Apr 15, 2013 at 9:10 PM, Olemis Lang <[email protected]> wrote: >>>> >>>>> On 4/15/13, Ryan Ollos <[email protected]> wrote: >>>>>> On Mon, Apr 15, 2013 at 5:54 PM, Olemis Lang <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi ! >>>>>>> >>>>>>> During the week end I created at Bibucket a fork of Trac >>>>>>> XmlRpcPlugin >>>>>>> to add in there compatibility for Bloodhound . We need that to >>>>>>> integrate some desktop applications with issue tracker , but there >>>>>>> are >>>>>>> other applications even for our own use . >>>>>>> >>>>>> Great! I think it has enough value that I'd like to see XmlRpcPlugin >>>>>> eventually become a component of the Bloodhound distribution. >>>>>> >>>>> AFAICR trac-dev was also considering merging that plugin into Trac >>>>> core once upon a time . >>>>> >>>>> Considering some plans and schedule for proposals (i.e. BEPs) this >>>>> seems to be imminent . Of course , they'd have to be fleshed out and >>>>> accepted first . Still in the fridge though . >>>>> >>>>>>> After reviewing the state of xmlrpcplugin trunk , now I tried to >>>>>>> run >>>>>>> its test suite . This is what I got >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> So I'm curious : what's the estimated time to bring contrib folder >>>>>>> back into BH trunk ? <= if such estimation is possible of course . >>>>>> There is a ticket (1) for adding license headers to the files in >>>>> 'contrib' >>>>>> and some other directories, and I felt that I took ticket as far >>>>>> as I >>>>> could >>>>>> without additional input from a Trac developer. Most everything >>>>>> looked >>>>> fine >>>>>> in terms of being able to put a BSD 3-Clause license on all, or >>>>>> nearly >>>>> all, >>>>>> of the files in 'contrib', but I'm not optimistic that there will >>>>>> be any >>>>>> status changes of the ticket for a while. >>>>>> >>>>> ... a law of Trac inertia ... they have other important things to do >>>>> too . For our own sake let's keep them focused on releasing high >>>>> quality code ;) >>>>> >>>>>> So if everyone agrees that we have a good case for adding back >>>>> 'contrib', I >>>>>> favor doing that and just removing it from the release tarball, >>>>> considering >>>>>> Brane said this would work okay. >>>>>> >>>>> if this triggers a vote , fwiw +1 >>>> Since there were no further comments to those by Olemis and Brane, I >>>> went >>>> ahead and restored `contrib` in r1469291. >>>> >>> I should clearly have said something earlier :) >>> >>> I think we are fine for the moment with this but if we once again need >>> to remove this at release time, even if only in the release artefacts, >>> we have only solved the problem for ourselves. If the ETA for >>> restoring contrib properly is far away, we might want to find another >>> solution to this so that users can also run the tests. >> The solution is, for example: >> >> svn export >> http://subversion.apache.org/repos/asf/bloodhound/tags/x.y.z/trac/contrib >> >> called optionally from the bloodhound installer script. >> >> Or even export directly from the core trac repository at a particular >> version. >> >> -- Brane >> > > Not a bad idea.. I would probably still go with dropping contrib from > trunk again for the next release if Trac do not solve the issue for > us, but we could do the optional export from > http://subversion.apache.org/repos/asf/bloodhound/vendor/trac/x.y.z/contrib
I'll say again: there's no need to drop contrib either from trunk or from the release branch. We can delete it from the tag as part of the release process. Yes, that means we modify tags. Subversion has been doing that for releases since ages ago, and no-one has complained we don't have an audit trail. :) > For this to work, it seems to rely on the assumption that the user has > subversion installed and that the user will know to run the installer > in a certain way to allow the tests to run. That we are probably > considering helping out a fairly small audience who would run the > tests here might make this kind of approach ok as long as they can > find the required information. I bet the number of users who want to run tests from a release tarball is smaller than the number of users with Subversion installed. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
