You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/07/25 19:18:25 UTC
[VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Hi everyone,
I hope that this is not premature but as the conversation on the related
[PROPOSAL] thread has died down, I would like to initiate the vote for
releasing Apache Bloodhound 0.1.0 (incubating). If successful this will
be the first release of the project and is an important step that I hope
will generate interest in the project and help the community to grow.
The release candidate this vote relates to provides:
* A patched version of Trac
* A new dashboard view with the dashboard style unifying views of
tickets, milestones and the user's dashboard.
* A re-theming of the interface to use bootstrap
* Preliminary multi-product support as a step towards allowing the
tracking of multiple distinct products (or projects) in a single
environment
* Simplified installation with the inclusion of a number of plugins as
standard.
As an initial release, of particular importance is that we have taken
proper notice of licensing of code produced as part of this project and
the proper acknowledgement of external work packaged with it.
The release candidate artifacts consist of source release as a tar.gz
archive along with the associated MD5 and GPG signature. These can be
found at: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
Please vote:
[ ] +1 Release this package as Apache Bloodhound 0.1.0
[ ] +0 Don't care
[ ] -1 Do not release this package (please explain)
The vote is open for 72 hours and, if successful, will be followed by a
vote on general@incubator for a further 72 hours.
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
I note that I have not explicitly indicated my vote (even if it has been
assumed implicitly) so:
+1 (binding)
On 07/25/2012 06:18 PM, Gary Martin wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the
> related [PROPOSAL] thread has died down, I would like to initiate the
> vote for releasing Apache Bloodhound 0.1.0 (incubating). If successful
> this will be the first release of the project and is an important step
> that I hope will generate interest in the project and help the
> community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins
> as standard.
>
> As an initial release, of particular importance is that we have taken
> proper notice of licensing of code produced as part of this project
> and the proper acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be
> found at: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by
> a vote on general@incubator for a further 72 hours.
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
Anybody with commit access can be an RM. People on the PPMC will vote on
their results.
Cheers,
-g
On Sep 24, 2012 5:21 AM, "Gary Martin" <ga...@wandisco.com> wrote:
> I agree too. I will check for anything that is obviously blocking though.
> Would anyone consider volunteering for release manager duties this time
> (Bloodhound PPMC member only I believe).
>
> Cheers,
> Gary
>
>
> On 09/23/2012 02:39 PM, Joe Dreimann wrote:
>
>> I'm with Greg on this. We should release every month in my opinion.
>>
>> - Joe
>>
>> ________________________
>> @jdreimann - Twitter
>> Sent from my phone
>>
>> On 23 Sep 2012, at 07:29, Greg Stein <gs...@gmail.com> wrote:
>>
>> On Sep 23, 2012 12:05 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>>>
>>>> On 9/21/12, Greg Stein <gs...@gmail.com> wrote:
>>>>
>>>>> It's been about 8 weeks... time to stop fixing, and start rolling?
>>>>>
>>>> There are some patches in the issue tracker , pending for commit .
>>>> Especially these tickets I consider important as they add some value
>>>> to what we shall propose , mainly regarding the UI .
>>>>
>>>> #203 , #53 , #138 , #139 , #201 , #45 , #174
>>>>
>>>> Beyond that , maybe we can postpone #146 and other tickets scheduled
>>>> for Release 2 , yet pending , for a forthcoming 0.2.1 , 0.3.0 , ...
>>>> whatever other release number it might be .
>>>>
>>> There are always future releases. IMO, no problem pushing changes out to
>>> the next one. This new release is better than the last, so you're in good
>>> shape.
>>>
>>> Further, if those patches in the tickets have not yet been applied, then
>>> maybe it is because they need some review, some testing, or whatever.
>>> They
>>> haven't (yet) been applied for some reason... so why delay further to
>>> wait
>>> for those reasons to be resolved? They'll hopefully be applied for the
>>> next-next release.
>>>
>>> (another happy benefit would be clearing out the IPMC concerns from the
>>> last release)
>>>
>>> Cheers,
>>> -g
>>>
>>
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
I agree too. I will check for anything that is obviously blocking
though. Would anyone consider volunteering for release manager duties
this time (Bloodhound PPMC member only I believe).
Cheers,
Gary
On 09/23/2012 02:39 PM, Joe Dreimann wrote:
> I'm with Greg on this. We should release every month in my opinion.
>
> - Joe
>
> ________________________
> @jdreimann - Twitter
> Sent from my phone
>
> On 23 Sep 2012, at 07:29, Greg Stein <gs...@gmail.com> wrote:
>
>> On Sep 23, 2012 12:05 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>>> On 9/21/12, Greg Stein <gs...@gmail.com> wrote:
>>>> It's been about 8 weeks... time to stop fixing, and start rolling?
>>> There are some patches in the issue tracker , pending for commit .
>>> Especially these tickets I consider important as they add some value
>>> to what we shall propose , mainly regarding the UI .
>>>
>>> #203 , #53 , #138 , #139 , #201 , #45 , #174
>>>
>>> Beyond that , maybe we can postpone #146 and other tickets scheduled
>>> for Release 2 , yet pending , for a forthcoming 0.2.1 , 0.3.0 , ...
>>> whatever other release number it might be .
>> There are always future releases. IMO, no problem pushing changes out to
>> the next one. This new release is better than the last, so you're in good
>> shape.
>>
>> Further, if those patches in the tickets have not yet been applied, then
>> maybe it is because they need some review, some testing, or whatever. They
>> haven't (yet) been applied for some reason... so why delay further to wait
>> for those reasons to be resolved? They'll hopefully be applied for the
>> next-next release.
>>
>> (another happy benefit would be clearing out the IPMC concerns from the
>> last release)
>>
>> Cheers,
>> -g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Joe Dreimann <jo...@wandisco.com>.
I'm with Greg on this. We should release every month in my opinion.
- Joe
________________________
@jdreimann - Twitter
Sent from my phone
On 23 Sep 2012, at 07:29, Greg Stein <gs...@gmail.com> wrote:
> On Sep 23, 2012 12:05 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>>
>> On 9/21/12, Greg Stein <gs...@gmail.com> wrote:
>>> It's been about 8 weeks... time to stop fixing, and start rolling?
>>
>> There are some patches in the issue tracker , pending for commit .
>> Especially these tickets I consider important as they add some value
>> to what we shall propose , mainly regarding the UI .
>>
>> #203 , #53 , #138 , #139 , #201 , #45 , #174
>>
>> Beyond that , maybe we can postpone #146 and other tickets scheduled
>> for Release 2 , yet pending , for a forthcoming 0.2.1 , 0.3.0 , ...
>> whatever other release number it might be .
>
> There are always future releases. IMO, no problem pushing changes out to
> the next one. This new release is better than the last, so you're in good
> shape.
>
> Further, if those patches in the tickets have not yet been applied, then
> maybe it is because they need some review, some testing, or whatever. They
> haven't (yet) been applied for some reason... so why delay further to wait
> for those reasons to be resolved? They'll hopefully be applied for the
> next-next release.
>
> (another happy benefit would be clearing out the IPMC concerns from the
> last release)
>
> Cheers,
> -g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Sep 23, 2012 12:05 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>
> On 9/21/12, Greg Stein <gs...@gmail.com> wrote:
> > It's been about 8 weeks... time to stop fixing, and start rolling?
> >
>
> There are some patches in the issue tracker , pending for commit .
> Especially these tickets I consider important as they add some value
> to what we shall propose , mainly regarding the UI .
>
> #203 , #53 , #138 , #139 , #201 , #45 , #174
>
> Beyond that , maybe we can postpone #146 and other tickets scheduled
> for Release 2 , yet pending , for a forthcoming 0.2.1 , 0.3.0 , ...
> whatever other release number it might be .
There are always future releases. IMO, no problem pushing changes out to
the next one. This new release is better than the last, so you're in good
shape.
Further, if those patches in the tickets have not yet been applied, then
maybe it is because they need some review, some testing, or whatever. They
haven't (yet) been applied for some reason... so why delay further to wait
for those reasons to be resolved? They'll hopefully be applied for the
next-next release.
(another happy benefit would be clearing out the IPMC concerns from the
last release)
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
On 9/21/12, Greg Stein <gs...@gmail.com> wrote:
> It's been about 8 weeks... time to stop fixing, and start rolling?
>
There are some patches in the issue tracker , pending for commit .
Especially these tickets I consider important as they add some value
to what we shall propose , mainly regarding the UI .
#203 , #53 , #138 , #139 , #201 , #45 , #174
Beyond that , maybe we can postpone #146 and other tickets scheduled
for Release 2 , yet pending , for a forthcoming 0.2.1 , 0.3.0 , ...
whatever other release number it might be .
;)
>
> ps. once it was announced, we've seen some new interest! round two? :-)
fwiw ... +1
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
It's been about 8 weeks... time to stop fixing, and start rolling?
Cheers,
-g
ps. once it was announced, we've seen some new interest! round two? :-)
On Jul 25, 2012 1:19 PM, "Gary Martin" <ga...@wandisco.com> wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the related
> [PROPOSAL] thread has died down, I would like to initiate the vote for
> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
> the first release of the project and is an important step that I hope will
> generate interest in the project and help the community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins as
> standard.
>
> As an initial release, of particular importance is that we have taken
> proper notice of licensing of code produced as part of this project and the
> proper acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be found
> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by a
> vote on general@incubator for a further 72 hours.
>
RE: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Gary Martin [mailto:gary.martin@wandisco.com]
> Sent: Tuesday, 7 August 2012 8:37 AM
> To: general@incubator.apache.org
> Cc: bloodhound-dev@incubator.apache.org
> Subject: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
>
> Hi,
>
> I would like to request the beginning of the vote for the first release
Apache
> Bloodhound in the incubator following the successful vote by the
> Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC
> members Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and KEYS
can
> be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release are
> listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after 11pm
> UTC on Thursday 9th August.
>
[ X] +1 Release this package as Apache Bloodhound 0.1.0
Gav...
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Aug 6, 2012 at 9:37 PM, Greg Stein <gs...@gmail.com> wrote:
> On Aug 6, 2012 7:07 PM, "Gary Martin" <ga...@wandisco.com> wrote:
>>...
>> The vote will be open for at least 72 hours and therefore ends after 11pm
> UTC on Thursday 9th August.
>>
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>
> Repeating my prior IPMC binding vote:
>
> +1 to release
Same. +1 (binding)
-Hyrum
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Aug 6, 2012 at 9:37 PM, Greg Stein <gs...@gmail.com> wrote:
> On Aug 6, 2012 7:07 PM, "Gary Martin" <ga...@wandisco.com> wrote:
>>...
>> The vote will be open for at least 72 hours and therefore ends after 11pm
> UTC on Thursday 9th August.
>>
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>
> Repeating my prior IPMC binding vote:
>
> +1 to release
Same. +1 (binding)
-Hyrum
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 6, 2012 7:07 PM, "Gary Martin" <ga...@wandisco.com> wrote:
>...
> The vote will be open for at least 72 hours and therefore ends after 11pm
UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
Repeating my prior IPMC binding vote:
+1 to release
Cheers,
-g
Re: Finalising release Was: Re: [RESULT] [VOTE] Release Apache Bloodhound
0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
On 08/10/2012 12:33 PM, Greg Stein wrote:
> Just move the files. No rename. Don't over think it. You've seen the votes.
> Get the release completed.
Good.. that is what I thought.
> Jira is having trouble, so email infrastructure@ once you've moved the
> files.
Excellent, as you can see I just did that. I remember trying to
subscribe to that list but I have not been successful. Perhaps that is
on purpose of course.
>
> Cheers,
> -g
> On Aug 10, 2012 5:32 AM, "Gary Martin" <ga...@wandisco.com> wrote:
>
>> Right, I should have discussed this last night but I was a little tired.
>>
>> All that is left to do is to copy or move the release files from
>> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>to
>> https://dist.apache.org/repos/**dist/release/incubator/**bloodhound/<https://dist.apache.org/repos/dist/release/incubator/bloodhound/>and then inform INFRA through
>> https://issues.apache.org/**jira/browse/INFRA-5057<https://issues.apache.org/jira/browse/INFRA-5057>(jira appears down to me at the moment though)
>>
>> I guess that as I have already created the files as
>> apache-bloodhound-incubating-**0.1.0-RC1.* I should leave them like this
>> and not worry too much about how that is interpreted. I suspect it could
>> take a while for Infra to be able to react so I will get on with this very
>> soon.
>>
>> Cheers,
>> Gary
>>
>>
>> On 08/10/2012 01:08 AM, Gary Martin wrote:
>>
>>> Sorry.. I appeared to forget to change the subject to reflect the vote
>>> ending.
>>>
>>> Cheers,
>>> Gary
>>>
>>> On 10/08/12 01:07, Gary Martin wrote:
>>>
>>>> Hi,
>>>>
>>>> So, it looks like we have already passed the 72 hour point and I am
>>>> pleased to note that we also appear to have a result.
>>>>
>>>> All IPMC binding votes from the bloodhound-dev part of the poll were
>>>> repeated here and so the results are:
>>>>
>>>> Gavin McDonald (binding) +1
>>>> Greg Stein (binding) +1
>>>> Hyrum Wright (binding) +1
>>>>
>>>> With 3 +1s I understand that release of Apache Bloodhound 0.1.0
>>>> (incubating) is approved. I will complete the process by moving the
>>>> artefacts from Bloodhound's /dist/dev area to the equivalent /dist/release
>>>> area in the morning.
>>>>
>>>> Thanks to all those who took part.
>>>>
>>>> Cheers,
>>>> Gary
>>>>
>>>>
>>>> On 07/08/12 00:07, Gary Martin wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to request the beginning of the vote for the first release
>>>>> Apache Bloodhound in the incubator following the successful vote by the
>>>>> Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC members
>>>>> Greg Stein and Hyrum Wright.
>>>>>
>>>>> The result of the vote is summarised here:
>>>>>
>>>>> http://markmail.org/message/**i3g5t2m7gajuoyv6<http://markmail.org/message/i3g5t2m7gajuoyv6>
>>>>>
>>>>> The artefacts for the release including the source distribution and
>>>>> KEYS can be found here:
>>>>>
>>>>> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>>>>
>>>>> The release itself is created from:
>>>>>
>>>>> https://svn.apache.org/repos/**asf/incubator/bloodhound/**
>>>>> branches/0.1<https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1>
>>>>> (r1362530)
>>>>>
>>>>> Issues identified by Greg and Hyrum to be fixed for the next release
>>>>> are listed here:
>>>>>
>>>>> https://issues.apache.org/**bloodhound/ticket/153<https://issues.apache.org/bloodhound/ticket/153>
>>>>>
>>>>>
>>>>> The vote will be open for at least 72 hours and therefore ends after
>>>>> 11pm UTC on Thursday 9th August.
>>>>>
>>>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>>>> [ ] +0 Don't care
>>>>> [ ] -1 Do not release this package (please explain)
>>>>>
>>>>> Cheers,
>>>>> Gary
>>>>>
>>>>
>>>> --
>>>> Gary Martin
>>>> gary.martin@wandisco.com
>>>> gjm@apache.org
>>>>
>>>
>>> --
>>> Gary Martin
>>> gary.martin@wandisco.com
>>> gjm@apache.org
>>>
>>
Re: Finalising release Was: Re: [RESULT] [VOTE] Release Apache
Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
Just move the files. No rename. Don't over think it. You've seen the votes.
Get the release completed.
Jira is having trouble, so email infrastructure@ once you've moved the
files.
Cheers,
-g
On Aug 10, 2012 5:32 AM, "Gary Martin" <ga...@wandisco.com> wrote:
> Right, I should have discussed this last night but I was a little tired.
>
> All that is left to do is to copy or move the release files from
> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>to
> https://dist.apache.org/repos/**dist/release/incubator/**bloodhound/<https://dist.apache.org/repos/dist/release/incubator/bloodhound/>and then inform INFRA through
> https://issues.apache.org/**jira/browse/INFRA-5057<https://issues.apache.org/jira/browse/INFRA-5057>(jira appears down to me at the moment though)
>
> I guess that as I have already created the files as
> apache-bloodhound-incubating-**0.1.0-RC1.* I should leave them like this
> and not worry too much about how that is interpreted. I suspect it could
> take a while for Infra to be able to react so I will get on with this very
> soon.
>
> Cheers,
> Gary
>
>
> On 08/10/2012 01:08 AM, Gary Martin wrote:
>
>> Sorry.. I appeared to forget to change the subject to reflect the vote
>> ending.
>>
>> Cheers,
>> Gary
>>
>> On 10/08/12 01:07, Gary Martin wrote:
>>
>>> Hi,
>>>
>>> So, it looks like we have already passed the 72 hour point and I am
>>> pleased to note that we also appear to have a result.
>>>
>>> All IPMC binding votes from the bloodhound-dev part of the poll were
>>> repeated here and so the results are:
>>>
>>> Gavin McDonald (binding) +1
>>> Greg Stein (binding) +1
>>> Hyrum Wright (binding) +1
>>>
>>> With 3 +1s I understand that release of Apache Bloodhound 0.1.0
>>> (incubating) is approved. I will complete the process by moving the
>>> artefacts from Bloodhound's /dist/dev area to the equivalent /dist/release
>>> area in the morning.
>>>
>>> Thanks to all those who took part.
>>>
>>> Cheers,
>>> Gary
>>>
>>>
>>> On 07/08/12 00:07, Gary Martin wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to request the beginning of the vote for the first release
>>>> Apache Bloodhound in the incubator following the successful vote by the
>>>> Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC members
>>>> Greg Stein and Hyrum Wright.
>>>>
>>>> The result of the vote is summarised here:
>>>>
>>>> http://markmail.org/message/**i3g5t2m7gajuoyv6<http://markmail.org/message/i3g5t2m7gajuoyv6>
>>>>
>>>> The artefacts for the release including the source distribution and
>>>> KEYS can be found here:
>>>>
>>>> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>>>
>>>> The release itself is created from:
>>>>
>>>> https://svn.apache.org/repos/**asf/incubator/bloodhound/**
>>>> branches/0.1<https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1>
>>>> (r1362530)
>>>>
>>>> Issues identified by Greg and Hyrum to be fixed for the next release
>>>> are listed here:
>>>>
>>>> https://issues.apache.org/**bloodhound/ticket/153<https://issues.apache.org/bloodhound/ticket/153>
>>>>
>>>>
>>>> The vote will be open for at least 72 hours and therefore ends after
>>>> 11pm UTC on Thursday 9th August.
>>>>
>>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>>> [ ] +0 Don't care
>>>> [ ] -1 Do not release this package (please explain)
>>>>
>>>> Cheers,
>>>> Gary
>>>>
>>>
>>>
>>> --
>>> Gary Martin
>>> gary.martin@wandisco.com
>>> gjm@apache.org
>>>
>>
>>
>> --
>> Gary Martin
>> gary.martin@wandisco.com
>> gjm@apache.org
>>
>
>
Finalising release Was: Re: [RESULT] [VOTE] Release Apache Bloodhound
0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Right, I should have discussed this last night but I was a little tired.
All that is left to do is to copy or move the release files from
https://dist.apache.org/repos/dist/dev/incubator/bloodhound/ to
https://dist.apache.org/repos/dist/release/incubator/bloodhound/ and
then inform INFRA through
https://issues.apache.org/jira/browse/INFRA-5057 (jira appears down to
me at the moment though)
I guess that as I have already created the files as
apache-bloodhound-incubating-0.1.0-RC1.* I should leave them like this
and not worry too much about how that is interpreted. I suspect it could
take a while for Infra to be able to react so I will get on with this
very soon.
Cheers,
Gary
On 08/10/2012 01:08 AM, Gary Martin wrote:
> Sorry.. I appeared to forget to change the subject to reflect the vote
> ending.
>
> Cheers,
> Gary
>
> On 10/08/12 01:07, Gary Martin wrote:
>> Hi,
>>
>> So, it looks like we have already passed the 72 hour point and I am
>> pleased to note that we also appear to have a result.
>>
>> All IPMC binding votes from the bloodhound-dev part of the poll were
>> repeated here and so the results are:
>>
>> Gavin McDonald (binding) +1
>> Greg Stein (binding) +1
>> Hyrum Wright (binding) +1
>>
>> With 3 +1s I understand that release of Apache Bloodhound 0.1.0
>> (incubating) is approved. I will complete the process by moving the
>> artefacts from Bloodhound's /dist/dev area to the equivalent
>> /dist/release area in the morning.
>>
>> Thanks to all those who took part.
>>
>> Cheers,
>> Gary
>>
>>
>> On 07/08/12 00:07, Gary Martin wrote:
>>> Hi,
>>>
>>> I would like to request the beginning of the vote for the first
>>> release Apache Bloodhound in the incubator following the successful
>>> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
>>> the IPMC members Greg Stein and Hyrum Wright.
>>>
>>> The result of the vote is summarised here:
>>>
>>> http://markmail.org/message/i3g5t2m7gajuoyv6
>>>
>>> The artefacts for the release including the source distribution and
>>> KEYS can be found here:
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>>>
>>> The release itself is created from:
>>>
>>> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
>>> (r1362530)
>>>
>>> Issues identified by Greg and Hyrum to be fixed for the next release
>>> are listed here:
>>>
>>> https://issues.apache.org/bloodhound/ticket/153
>>>
>>>
>>> The vote will be open for at least 72 hours and therefore ends after
>>> 11pm UTC on Thursday 9th August.
>>>
>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>> [ ] +0 Don't care
>>> [ ] -1 Do not release this package (please explain)
>>>
>>> Cheers,
>>> Gary
>>
>>
>> --
>> Gary Martin
>> gary.martin@wandisco.com
>> gjm@apache.org
>
>
> --
> Gary Martin
> gary.martin@wandisco.com
> gjm@apache.org
[RESULT] [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Sorry.. I appeared to forget to change the subject to reflect the vote
ending.
Cheers,
Gary
On 10/08/12 01:07, Gary Martin wrote:
> Hi,
>
> So, it looks like we have already passed the 72 hour point and I am
> pleased to note that we also appear to have a result.
>
> All IPMC binding votes from the bloodhound-dev part of the poll were
> repeated here and so the results are:
>
> Gavin McDonald (binding) +1
> Greg Stein (binding) +1
> Hyrum Wright (binding) +1
>
> With 3 +1s I understand that release of Apache Bloodhound 0.1.0
> (incubating) is approved. I will complete the process by moving the
> artefacts from Bloodhound's /dist/dev area to the equivalent
> /dist/release area in the morning.
>
> Thanks to all those who took part.
>
> Cheers,
> Gary
>
>
> On 07/08/12 00:07, Gary Martin wrote:
>> Hi,
>>
>> I would like to request the beginning of the vote for the first
>> release Apache Bloodhound in the incubator following the successful
>> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
>> the IPMC members Greg Stein and Hyrum Wright.
>>
>> The result of the vote is summarised here:
>>
>> http://markmail.org/message/i3g5t2m7gajuoyv6
>>
>> The artefacts for the release including the source distribution and
>> KEYS can be found here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>>
>> The release itself is created from:
>>
>> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1 (r1362530)
>>
>> Issues identified by Greg and Hyrum to be fixed for the next release
>> are listed here:
>>
>> https://issues.apache.org/bloodhound/ticket/153
>>
>>
>> The vote will be open for at least 72 hours and therefore ends after
>> 11pm UTC on Thursday 9th August.
>>
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>>
>> Cheers,
>> Gary
>
>
> --
> Gary Martin
> gary.martin@wandisco.com
> gjm@apache.org
--
Gary Martin
gary.martin@wandisco.com
gjm@apache.org
[RESULT] [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Sorry.. I appeared to forget to change the subject to reflect the vote
ending.
Cheers,
Gary
On 10/08/12 01:07, Gary Martin wrote:
> Hi,
>
> So, it looks like we have already passed the 72 hour point and I am
> pleased to note that we also appear to have a result.
>
> All IPMC binding votes from the bloodhound-dev part of the poll were
> repeated here and so the results are:
>
> Gavin McDonald (binding) +1
> Greg Stein (binding) +1
> Hyrum Wright (binding) +1
>
> With 3 +1s I understand that release of Apache Bloodhound 0.1.0
> (incubating) is approved. I will complete the process by moving the
> artefacts from Bloodhound's /dist/dev area to the equivalent
> /dist/release area in the morning.
>
> Thanks to all those who took part.
>
> Cheers,
> Gary
>
>
> On 07/08/12 00:07, Gary Martin wrote:
>> Hi,
>>
>> I would like to request the beginning of the vote for the first
>> release Apache Bloodhound in the incubator following the successful
>> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
>> the IPMC members Greg Stein and Hyrum Wright.
>>
>> The result of the vote is summarised here:
>>
>> http://markmail.org/message/i3g5t2m7gajuoyv6
>>
>> The artefacts for the release including the source distribution and
>> KEYS can be found here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>>
>> The release itself is created from:
>>
>> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1 (r1362530)
>>
>> Issues identified by Greg and Hyrum to be fixed for the next release
>> are listed here:
>>
>> https://issues.apache.org/bloodhound/ticket/153
>>
>>
>> The vote will be open for at least 72 hours and therefore ends after
>> 11pm UTC on Thursday 9th August.
>>
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>>
>> Cheers,
>> Gary
>
>
> --
> Gary Martin
> gary.martin@wandisco.com
> gjm@apache.org
--
Gary Martin
gary.martin@wandisco.com
gjm@apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
So, it looks like we have already passed the 72 hour point and I am
pleased to note that we also appear to have a result.
All IPMC binding votes from the bloodhound-dev part of the poll were
repeated here and so the results are:
Gavin McDonald (binding) +1
Greg Stein (binding) +1
Hyrum Wright (binding) +1
With 3 +1s I understand that release of Apache Bloodhound 0.1.0
(incubating) is approved. I will complete the process by moving the
artefacts from Bloodhound's /dist/dev area to the equivalent
/dist/release area in the morning.
Thanks to all those who took part.
Cheers,
Gary
On 07/08/12 00:07, Gary Martin wrote:
> Hi,
>
> I would like to request the beginning of the vote for the first
> release Apache Bloodhound in the incubator following the successful
> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
> the IPMC members Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and
> KEYS can be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release
> are listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after
> 11pm UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> Cheers,
> Gary
--
Gary Martin
gary.martin@wandisco.com
gjm@apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
So, it looks like we have already passed the 72 hour point and I am
pleased to note that we also appear to have a result.
All IPMC binding votes from the bloodhound-dev part of the poll were
repeated here and so the results are:
Gavin McDonald (binding) +1
Greg Stein (binding) +1
Hyrum Wright (binding) +1
With 3 +1s I understand that release of Apache Bloodhound 0.1.0
(incubating) is approved. I will complete the process by moving the
artefacts from Bloodhound's /dist/dev area to the equivalent
/dist/release area in the morning.
Thanks to all those who took part.
Cheers,
Gary
On 07/08/12 00:07, Gary Martin wrote:
> Hi,
>
> I would like to request the beginning of the vote for the first
> release Apache Bloodhound in the incubator following the successful
> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
> the IPMC members Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and
> KEYS can be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release
> are listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after
> 11pm UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> Cheers,
> Gary
--
Gary Martin
gary.martin@wandisco.com
gjm@apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 6, 2012 7:07 PM, "Gary Martin" <ga...@wandisco.com> wrote:
>...
> The vote will be open for at least 72 hours and therefore ends after 11pm
UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
Repeating my prior IPMC binding vote:
+1 to release
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Branko Čibej <br...@e-reka.si>.
On 07.08.2012 01:07, Gary Martin wrote:
> Hi,
>
> I would like to request the beginning of the vote for the first
> release Apache Bloodhound in the incubator following the successful
> vote by the Bloodhound PPMC. Two of the four +1 PPMC votes were from
> the IPMC members Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and
> KEYS can be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release
> are listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after
> 11pm UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
+1 for release.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Gary Martin [mailto:gary.martin@wandisco.com]
> Sent: Tuesday, 7 August 2012 8:37 AM
> To: general@incubator.apache.org
> Cc: bloodhound-dev@incubator.apache.org
> Subject: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
>
> Hi,
>
> I would like to request the beginning of the vote for the first release
Apache
> Bloodhound in the incubator following the successful vote by the
> Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC
> members Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and KEYS
can
> be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release are
> listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after 11pm
> UTC on Thursday 9th August.
>
[ X] +1 Release this package as Apache Bloodhound 0.1.0
Gav...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by ant elder <an...@gmail.com>.
On Wed, Aug 8, 2012 at 3:19 PM, Alexei Fedotov <al...@gmail.com> wrote:
> Hello,
>
> Let me add one more point on adding dependencies to source releases.
> In addition to license, the dependence contain copyright statements,
> e.g. "# Copyright (C) 2005 Christopher Lenz <cm...@gmx.de>".
>
> As mentioned here http://www.apache.org/legal/src-headers.html
>> If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either:
>> remove such notices, or
>> move them to the NOTICE file associated with each applicable project release, or
>> provide written permission for the ASF to make such removal or relocation of the notices.
>
> This issue cannot be fixed by merging licenses into LICENSE file.
>
No, this is not what that source headers page is talking about. That
page is talking about any copyright statements that may have been in
source files when contributed to the ASF, here we are talking about
the licenses of any external dependencies that are included in a
release, and those licenses should be added to the LICENSE file, as
described at: http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Alexei Fedotov <al...@gmail.com>.
Hello,
Let me add one more point on adding dependencies to source releases.
In addition to license, the dependence contain copyright statements,
e.g. "# Copyright (C) 2005 Christopher Lenz <cm...@gmx.de>".
As mentioned here http://www.apache.org/legal/src-headers.html
> If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either:
> remove such notices, or
> move them to the NOTICE file associated with each applicable project release, or
> provide written permission for the ASF to make such removal or relocation of the notices.
This issue cannot be fixed by merging licenses into LICENSE file.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Aug 8, 2012 at 11:26 AM, ant elder <an...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 1:13 AM, Greg Stein <gs...@gmail.com> wrote:
>> On Tue, Aug 7, 2012 at 5:54 PM, ant elder <an...@gmail.com> wrote:
>>> On Tue, Aug 7, 2012 at 9:51 PM, Greg Stein <gs...@gmail.com> wrote:
>>>...
>>>> You can look at the archives back in 2006 when it was incubating. In
>>>> particular, there is one sent to private@incubator that I would refer
>>>> you to:
>>>> http://s.apache.org/c04 [only usable by ASF Members]
>>>>
>>>
>>> Didn't that get subsequently revised by Cliff et al into "Incubating
>>> projects must not distribute an official product release that includes
>>> works covered by an excluded license" -
>>> http://www.apache.org/legal/3party.html#transition-incubator
>>
>> Dunno. That link is for a draft document, and has been replaced by a
>> final/resolved form (see link at top of page).
>>
>> Regardless... Jukka posted recently, and I'd look to his note for
>> "current policy". I think his statement puts Incubator policy a little
>> more relaxed than ASF, but likely not as relaxed as I would have
>> posited (in regards to dependencies).
>>
>
> The good thing about release votes is that they can't be vetoed so
> regardless of what policies may or may not be documented whether or
> not a release vote passes is just down to getting enough people to
> vote +1. Votes on general@ often stall and require a respin when
> someone claims something is wrong which puts off others from voting.
> Something as basic as a dependent license missing from the LICENSE
> file would be one of those things that in the past would have always
> demanded a respin, so the change, and it is a change, to allow wiggle
> room is what i hope people will remember from this.
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by ant elder <an...@gmail.com>.
On Wed, Aug 8, 2012 at 1:13 AM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 5:54 PM, ant elder <an...@gmail.com> wrote:
>> On Tue, Aug 7, 2012 at 9:51 PM, Greg Stein <gs...@gmail.com> wrote:
>>...
>>> You can look at the archives back in 2006 when it was incubating. In
>>> particular, there is one sent to private@incubator that I would refer
>>> you to:
>>> http://s.apache.org/c04 [only usable by ASF Members]
>>>
>>
>> Didn't that get subsequently revised by Cliff et al into "Incubating
>> projects must not distribute an official product release that includes
>> works covered by an excluded license" -
>> http://www.apache.org/legal/3party.html#transition-incubator
>
> Dunno. That link is for a draft document, and has been replaced by a
> final/resolved form (see link at top of page).
>
> Regardless... Jukka posted recently, and I'd look to his note for
> "current policy". I think his statement puts Incubator policy a little
> more relaxed than ASF, but likely not as relaxed as I would have
> posited (in regards to dependencies).
>
The good thing about release votes is that they can't be vetoed so
regardless of what policies may or may not be documented whether or
not a release vote passes is just down to getting enough people to
vote +1. Votes on general@ often stall and require a respin when
someone claims something is wrong which puts off others from voting.
Something as basic as a dependent license missing from the LICENSE
file would be one of those things that in the past would have always
demanded a respin, so the change, and it is a change, to allow wiggle
room is what i hope people will remember from this.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 7, 2012 at 5:54 PM, ant elder <an...@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 9:51 PM, Greg Stein <gs...@gmail.com> wrote:
>...
>> You can look at the archives back in 2006 when it was incubating. In
>> particular, there is one sent to private@incubator that I would refer
>> you to:
>> http://s.apache.org/c04 [only usable by ASF Members]
>>
>
> Didn't that get subsequently revised by Cliff et al into "Incubating
> projects must not distribute an official product release that includes
> works covered by an excluded license" -
> http://www.apache.org/legal/3party.html#transition-incubator
Dunno. That link is for a draft document, and has been replaced by a
final/resolved form (see link at top of page).
Regardless... Jukka posted recently, and I'd look to his note for
"current policy". I think his statement puts Incubator policy a little
more relaxed than ASF, but likely not as relaxed as I would have
posited (in regards to dependencies).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 7, 2012 at 9:51 PM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 3:44 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> On Tue, Aug 7, 2012 at 11:38 AM, ant elder <an...@gmail.com> wrote:
>>> Gosh i'm pretty sure we _don't_ allow things like (L)GPL dependencies
>>> in Incubator releases, we allow them in the source in SVN but i don't
>>> recall any releases like that.
>>
>> I know AOO had interactions with Legal regarding dmake, dictionaries and so
>> on, though I don't recall exactly what went into their release. I would be
>> surprised if any category X dependencies have wound up in an incubating
>> release without Legal's involvement.
>>
>> Lucy's early incubating releases had two Perl-licensed (Artistic/GPL)
>> dependencies (which were not bundled, but had to be downloaded and installed
>> separately by the consumer). We sought a variance from Legal and got specific
>> approval from the Legal VP for our plan, which involved ditching both of the
>> problematic dependencies prior to graduation:
>>
>> https://issues.apache.org/jira/browse/LEGAL-86
>>
>> Are there other examples?
>
> The one that I had in mind was Roller. Several of its incubating
> releases had a hard dependency on Hibernate. They were required to
> clean it up before graduation, of course.
>
> You can look at the archives back in 2006 when it was incubating. In
> particular, there is one sent to private@incubator that I would refer
> you to:
> http://s.apache.org/c04 [only usable by ASF Members]
>
Didn't that get subsequently revised by Cliff et al into "Incubating
projects must not distribute an official product release that includes
works covered by an excluded license" -
http://www.apache.org/legal/3party.html#transition-incubator
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 7, 2012 at 3:44 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Tue, Aug 7, 2012 at 11:38 AM, ant elder <an...@gmail.com> wrote:
>> Gosh i'm pretty sure we _don't_ allow things like (L)GPL dependencies
>> in Incubator releases, we allow them in the source in SVN but i don't
>> recall any releases like that.
>
> I know AOO had interactions with Legal regarding dmake, dictionaries and so
> on, though I don't recall exactly what went into their release. I would be
> surprised if any category X dependencies have wound up in an incubating
> release without Legal's involvement.
>
> Lucy's early incubating releases had two Perl-licensed (Artistic/GPL)
> dependencies (which were not bundled, but had to be downloaded and installed
> separately by the consumer). We sought a variance from Legal and got specific
> approval from the Legal VP for our plan, which involved ditching both of the
> problematic dependencies prior to graduation:
>
> https://issues.apache.org/jira/browse/LEGAL-86
>
> Are there other examples?
The one that I had in mind was Roller. Several of its incubating
releases had a hard dependency on Hibernate. They were required to
clean it up before graduation, of course.
You can look at the archives back in 2006 when it was incubating. In
particular, there is one sent to private@incubator that I would refer
you to:
http://s.apache.org/c04 [only usable by ASF Members]
>> Anyway thats beside the point, ok so lets have this be a precedent
>> that sets Incubator policy - we now have some wiggle room while
>> incubating to do a release that violates ASF release policy as long as
>> it will be fixed soon in another release and definitely before
>> graduating.
>
> It seems that with regards to this Bloodhound release, the issue is restricted
> to LICENSE/NOTICE, an area where ASF policies are notoriously unclear and
> conformance is arguably spotty even among TLPs.
I've given some bad info in the past, but after the last go-round
(thanks Marvin), I feel that I've got a better handle on it. And
that's the feedback that I've now provided to the BH people.
> So long as the licenses of
> all dependencies are being obeyed (e.g. no license headers or mandatory files
> stripped from source files) and usage is compatible with ASF policy (no
> category X dependencies, etc),
All good here.
> I agree with the judgment call that an
> incubating release need not be held up simply to move the text of the license
> from LICENSE to NOTICE or vice versa.
>
> IMO, this is different from releases with category X dependencies, where ASF
> policies are clear and conformance is very high among TLPs. I don't see that
> the Incubator should consider this vote a precedent for overturning arbitrary
> ASF policy.
For TLPs, I totally agree. For projects that are incubating... they
are NOT ASF projects by definition. That is why we've allowed a bit of
wiggle.
In any case, Bloodhound isn't requesting any funny deps. Just getting
a release out there which some already-known issues. That's why it got
my +1, and recommendation to just go with 0.1.0 rather than spinning
up a new tarball.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Aug 7, 2012 at 11:38 AM, ant elder <an...@gmail.com> wrote:
> Gosh i'm pretty sure we _don't_ allow things like (L)GPL dependencies
> in Incubator releases, we allow them in the source in SVN but i don't
> recall any releases like that.
I know AOO had interactions with Legal regarding dmake, dictionaries and so
on, though I don't recall exactly what went into their release. I would be
surprised if any category X dependencies have wound up in an incubating
release without Legal's involvement.
Lucy's early incubating releases had two Perl-licensed (Artistic/GPL)
dependencies (which were not bundled, but had to be downloaded and installed
separately by the consumer). We sought a variance from Legal and got specific
approval from the Legal VP for our plan, which involved ditching both of the
problematic dependencies prior to graduation:
https://issues.apache.org/jira/browse/LEGAL-86
Are there other examples?
> Anyway thats beside the point, ok so lets have this be a precedent
> that sets Incubator policy - we now have some wiggle room while
> incubating to do a release that violates ASF release policy as long as
> it will be fixed soon in another release and definitely before
> graduating.
It seems that with regards to this Bloodhound release, the issue is restricted
to LICENSE/NOTICE, an area where ASF policies are notoriously unclear and
conformance is arguably spotty even among TLPs. So long as the licenses of
all dependencies are being obeyed (e.g. no license headers or mandatory files
stripped from source files) and usage is compatible with ASF policy (no
category X dependencies, etc), I agree with the judgment call that an
incubating release need not be held up simply to move the text of the license
from LICENSE to NOTICE or vice versa.
IMO, this is different from releases with category X dependencies, where ASF
policies are clear and conformance is very high among TLPs. I don't see that
the Incubator should consider this vote a precedent for overturning arbitrary
ASF policy.
If we don't like the poor state of ASF policy and conformance on
LICENSE/NOTICE then the ASF Membership should work to clarify the policy.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[DISCUSS] [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
[branching a discuss thread]
On Tue, Aug 7, 2012 at 10:56 PM, Greg Stein <gs...@gmail.com> wrote:
> As I replied to Marvin, Apache Roller had a hard dependency on
> Hibernate for some of its incubator releases. Allowing that was okay'd
> by the IPMC, VP Legal, and the Board :-)
>
> My view is that these are not true ASF projects, so *some* wiggle is
> allowable, especially with a plan in hand.
Note that even though podlings aren't full Apache projects yet,
incubating releases *are* official Apache releases, and should
therefore be held to a similar standard. If that standard can't easily
be reached, some podlings (like Subversion when it came in) have opted
to keep cutting non-Apache releases outside the ASF until those issues
have been resolved.
> It's certainly a subjective judgement call. I don't know where to draw
> the line, nor whether we must draw it. One of those "know it when you
> see it" things. And we have the judgement of a large body of people
> here on this list.
Personally I'm fine with things like missing license headers or
partially incomplete license metadata (which sounds like is the case
here), as long as those are just omissions that don't fundamentally
affect our rights (or those of downstream users) to distribute the
releases and as long as there's a commitment to fix such issues in
time for the next release. Such minor issues are fairly common also in
many TLPs (I've filed a number of related bugs), so it's not even a
problem that's limited just to the Incubator.
Larger issues like exceptions to documented licensing policy (like in
the examples brought up here) should always be explicitly cleared with
legal, etc.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 7, 2012 at 2:38 PM, ant elder <an...@gmail.com> wrote:
>...
> Gosh i'm pretty sure we _don't_ allow things like (L)GPL dependencies
> in Incubator releases, we allow them in the source in SVN but i don't
> recall any releases like that.
As I replied to Marvin, Apache Roller had a hard dependency on
Hibernate for some of its incubator releases. Allowing that was okay'd
by the IPMC, VP Legal, and the Board :-)
My view is that these are not true ASF projects, so *some* wiggle is
allowable, especially with a plan in hand.
(now, I still would not advocate for any release that seriously broke
the rules; at a minimum, get LICENSE/NOTICE and source file headers in
there; work on clarifying your dependencies and their licenses; etc)
> Anyway thats beside the point, ok so lets have this be a precedent
> that sets Incubator policy - we now have some wiggle room while
> incubating to do a release that violates ASF release policy as long as
> it will be fixed soon in another release and definitely before
> graduating. A policy like that would help a lot with avoiding the
> numerous respins some poddling releases are made to do during voting
> on general@.
Exactly. We've seen a lot of back/forth which doesn't really help the
podling very much.
It's certainly a subjective judgement call. I don't know where to draw
the line, nor whether we must draw it. One of those "know it when you
see it" things. And we have the judgement of a large body of people
here on this list.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 7, 2012 at 6:04 PM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 7:14 AM, ant elder <an...@gmail.com> wrote:
>>...
>> This looks similar to the Syncope release vote thats also happening
>> right now in that the source distribution includes things like JQuery
>> but doesn't mention that in the LICENSE file. I'm a bit surprised
>> people are continuing to vote +1 on the Syncope release knowing that
>> so am I getting this wrong and the JQuery license doesn't need to be
>> included here for some reason?
>
> My feeling on the matter here is that these are incubating projects.
> We allow things like (L)GPL dependencies in the releases, as long as a
> PLAN exists to get rid of them. Of course, it must be perfectly clean
> to graduate. But I believe we have wiggle room while incubating.
>
> As Branko noted, the included projects are mentioned in the NOTICE
> file, but that isn't quite Right. The 0.2.0 release will get it
> corrected.
>
> We could have stepped back and rolled another tarball, but I believe
> it is more important for Bloodhound to get a release out [than to be
> perfect on 0.1.0], in order to get some traction and some attraction
> to build a larger community. The BH folks plan to release every few
> weeks, so we should see the corrections in a release at the end of the
> month. (or we could convince Gary to do another in a week or two :-)
>
> Cheers,
> -g
>
Gosh i'm pretty sure we _don't_ allow things like (L)GPL dependencies
in Incubator releases, we allow them in the source in SVN but i don't
recall any releases like that.
Anyway thats beside the point, ok so lets have this be a precedent
that sets Incubator policy - we now have some wiggle room while
incubating to do a release that violates ASF release policy as long as
it will be fixed soon in another release and definitely before
graduating. A policy like that would help a lot with avoiding the
numerous respins some poddling releases are made to do during voting
on general@.
...ant
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 7, 2012 at 7:14 AM, ant elder <an...@gmail.com> wrote:
>...
> This looks similar to the Syncope release vote thats also happening
> right now in that the source distribution includes things like JQuery
> but doesn't mention that in the LICENSE file. I'm a bit surprised
> people are continuing to vote +1 on the Syncope release knowing that
> so am I getting this wrong and the JQuery license doesn't need to be
> included here for some reason?
My feeling on the matter here is that these are incubating projects.
We allow things like (L)GPL dependencies in the releases, as long as a
PLAN exists to get rid of them. Of course, it must be perfectly clean
to graduate. But I believe we have wiggle room while incubating.
As Branko noted, the included projects are mentioned in the NOTICE
file, but that isn't quite Right. The 0.2.0 release will get it
corrected.
We could have stepped back and rolled another tarball, but I believe
it is more important for Bloodhound to get a release out [than to be
perfect on 0.1.0], in order to get some traction and some attraction
to build a larger community. The BH folks plan to release every few
weeks, so we should see the corrections in a release at the end of the
month. (or we could convince Gary to do another in a week or two :-)
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
On 08/07/2012 12:39 PM, Branko Čibej wrote:
> On 07.08.2012 13:14, ant elder wrote:
>> This looks similar to the Syncope release vote thats also happening
>> right now in that the source distribution includes things like JQuery
>> but doesn't mention that in the LICENSE file. I'm a bit surprised
>> people are continuing to vote +1 on the Syncope release knowing that
>> so am I getting this wrong and the JQuery license doesn't need to be
>> included here for some reason?
> The NOTICE file explicitly notes external dependencies and their
> (standard) licenses. Combined with the ticket that mentions adding
> licenses of said dependencies to LICENSE, IMO, this is good enough for a
> release candidate.
>
> -- Brane
>
I think it is also worth noting that Greg Stein has already mentioned
this - see the first item in
https://issues.apache.org/bloodhound/ticket/153 (which also contains the
link to Greg's email) - and so this will be attended to in the next release.
Cheers,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Branko Čibej <br...@apache.org>.
On 07.08.2012 13:14, ant elder wrote:
> This looks similar to the Syncope release vote thats also happening
> right now in that the source distribution includes things like JQuery
> but doesn't mention that in the LICENSE file. I'm a bit surprised
> people are continuing to vote +1 on the Syncope release knowing that
> so am I getting this wrong and the JQuery license doesn't need to be
> included here for some reason?
The NOTICE file explicitly notes external dependencies and their
(standard) licenses. Combined with the ticket that mentions adding
licenses of said dependencies to LICENSE, IMO, this is good enough for a
release candidate.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 7, 2012 at 12:07 AM, Gary Martin <ga...@wandisco.com> wrote:
> Hi,
>
> I would like to request the beginning of the vote for the first release
> Apache Bloodhound in the incubator following the successful vote by the
> Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC members
> Greg Stein and Hyrum Wright.
>
> The result of the vote is summarised here:
>
> http://markmail.org/message/i3g5t2m7gajuoyv6
>
> The artefacts for the release including the source distribution and KEYS can
> be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> The release itself is created from:
>
> https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
> (r1362530)
>
> Issues identified by Greg and Hyrum to be fixed for the next release are
> listed here:
>
> https://issues.apache.org/bloodhound/ticket/153
>
>
> The vote will be open for at least 72 hours and therefore ends after 11pm
> UTC on Thursday 9th August.
>
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> Cheers,
> Gary
This looks similar to the Syncope release vote thats also happening
right now in that the source distribution includes things like JQuery
but doesn't mention that in the LICENSE file. I'm a bit surprised
people are continuing to vote +1 on the Syncope release knowing that
so am I getting this wrong and the JQuery license doesn't need to be
included here for some reason?
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
I would like to request the beginning of the vote for the first release
Apache Bloodhound in the incubator following the successful vote by the
Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC
members Greg Stein and Hyrum Wright.
The result of the vote is summarised here:
http://markmail.org/message/i3g5t2m7gajuoyv6
The artefacts for the release including the source distribution and KEYS
can be found here:
https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
The release itself is created from:
https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
(r1362530)
Issues identified by Greg and Hyrum to be fixed for the next release are
listed here:
https://issues.apache.org/bloodhound/ticket/153
The vote will be open for at least 72 hours and therefore ends after
11pm UTC on Thursday 9th August.
[ ] +1 Release this package as Apache Bloodhound 0.1.0
[ ] +0 Don't care
[ ] -1 Do not release this package (please explain)
Cheers,
Gary
[VOTE] Release Apache Bloodhound 0.1.0 (incubating)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
I would like to request the beginning of the vote for the first release
Apache Bloodhound in the incubator following the successful vote by the
Bloodhound PPMC. Two of the four +1 PPMC votes were from the IPMC
members Greg Stein and Hyrum Wright.
The result of the vote is summarised here:
http://markmail.org/message/i3g5t2m7gajuoyv6
The artefacts for the release including the source distribution and KEYS
can be found here:
https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
The release itself is created from:
https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.1
(r1362530)
Issues identified by Greg and Hyrum to be fixed for the next release are
listed here:
https://issues.apache.org/bloodhound/ticket/153
The vote will be open for at least 72 hours and therefore ends after
11pm UTC on Thursday 9th August.
[ ] +1 Release this package as Apache Bloodhound 0.1.0
[ ] +0 Don't care
[ ] -1 Do not release this package (please explain)
Cheers,
Gary
Re: [RESULT] [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 6, 2012 7:09 AM, "Gary Martin" <ga...@wandisco.com> wrote:
>
> On 08/06/2012 11:51 AM, Gary Martin wrote:
>>
>> Time to call the result I think.
>>
>> Mentor votes:
>>
>> [2] +1
>> [0] +0
>> [0] -1
>>
>> Other PPMC votes:
>>
>> [2] +1
>> [0] +0
>> [0] -1
>>
>> The vote is therefore successful with 4 binding votes.
>>
>> The following is a full voting record in voting order, including those
that I understand to be non-binding votes:
>>
>> Mark Poole: +1
>> Joachim Dreimann: +1 (non-binding)
>> Olemis Lang: +1 (non-binding)
>> Greg Stein: +1
>> Ethan Jucovy: -1 (non-binding)
>> Hyrum Wright: +1
>> Gary Martin: +1
>>
>
> If everyone is happy that the above is an accurate account, I will write
a new email to start the VOTE on general@incubator.
JFDI.
:-P
Re: [RESULT] [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
(RC1)
Posted by Gary Martin <ga...@wandisco.com>.
On 08/06/2012 11:51 AM, Gary Martin wrote:
> Time to call the result I think.
>
> Mentor votes:
>
> [2] +1
> [0] +0
> [0] -1
>
> Other PPMC votes:
>
> [2] +1
> [0] +0
> [0] -1
>
> The vote is therefore successful with 4 binding votes.
>
> The following is a full voting record in voting order, including those
> that I understand to be non-binding votes:
>
> Mark Poole: +1
> Joachim Dreimann: +1 (non-binding)
> Olemis Lang: +1 (non-binding)
> Greg Stein: +1
> Ethan Jucovy: -1 (non-binding)
> Hyrum Wright: +1
> Gary Martin: +1
>
If everyone is happy that the above is an accurate account, I will write
a new email to start the VOTE on general@incubator.
Cheers,
Gary
[RESULT] [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Time to call the result I think.
Mentor votes:
[2] +1
[0] +0
[0] -1
Other PPMC votes:
[2] +1
[0] +0
[0] -1
The vote is therefore successful with 4 binding votes.
The following is a full voting record in voting order, including those
that I understand to be non-binding votes:
Mark Poole: +1
Joachim Dreimann: +1 (non-binding)
Olemis Lang: +1 (non-binding)
Greg Stein: +1
Ethan Jucovy: -1 (non-binding)
Hyrum Wright: +1
Gary Martin: +1
On 07/25/2012 06:18 PM, Gary Martin wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the
> related [PROPOSAL] thread has died down, I would like to initiate the
> vote for releasing Apache Bloodhound 0.1.0 (incubating). If successful
> this will be the first release of the project and is an important step
> that I hope will generate interest in the project and help the
> community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins
> as standard.
>
> As an initial release, of particular importance is that we have taken
> proper notice of licensing of code produced as part of this project
> and the proper acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be
> found at: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by
> a vote on general@incubator for a further 72 hours.
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
Right. We're voting on the specific tarball. We're saying "this is
something the ASF can stand behind".
If Olemis took the tarball contents and manually installed it and/or
reviewed it in detail, then that's good enough. The auto-install
script doesn't have to work for it to be releasable. As I've mentioned
before, there can be lots of bugs; those will just get fixed in future
releases.
I'm going to be reviewing the contents, rather than the operation. I
don't care if it works. I just want to be sure the licensing and
notices are right, and that the tarball doesn't have trojans or other
malware in there. I'll also check the md5 (tho not set up to check the
sig right now).
Should be done in an hour or so...
Cheers,
-g
On Wed, Aug 1, 2012 at 9:32 PM, Gary Martin <ga...@wandisco.com> wrote:
> Thanks for the response Olemis.
>
> The advice from Greg might have been interpreted to mean that all voters
> should be checking the release carefully before voting. This seems helpful
> as any input into whether the release is fit is better if it is informed by
> some level of checking.
>
> I don't have a definitive answer although it would seem sensible for the
> Bloodhound PPMC to take particular note of Greg's advice.
>
> Cheers,
> Gary
>
>
>
> On 02/08/12 01:57, Olemis Lang wrote:
>>
>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>
>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>
>>>> Just for the record, I have downloaded reviewed the files to my
>>>> technical
>>>> ability.
>>>>
>>>> +1 for the release from me.
>>>>
>> I second that . The only thing I can mention is that even if manual
>> installation procedure works for me , on the other hand all the
>> attempts I made so as to install it from tarball in a Jenkins build
>> job have failed . This is mainly because :
>>
>> 1. I'm not a proficient Jenkins user ...
>> 2. it seems there's an issue with virtualenv somewhere and ...
>> 3. I've not been able to dedicate any time to this task after the
>> few initial experiments
>>
>> That's obviously not a reason to stop release tarball from being
>> released , so ...
>>
>> +1 for release
>>
>>> The following is a short description of how to verify that the package
>>> is signed:
>>>
>> [...]
>>
>> ... and all these checks , well I've not tried them yet . Should I ?
>>
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Thanks for the response Olemis.
The advice from Greg might have been interpreted to mean that all voters
should be checking the release carefully before voting. This seems
helpful as any input into whether the release is fit is better if it is
informed by some level of checking.
I don't have a definitive answer although it would seem sensible for the
Bloodhound PPMC to take particular note of Greg's advice.
Cheers,
Gary
On 02/08/12 01:57, Olemis Lang wrote:
> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>> Just for the record, I have downloaded reviewed the files to my technical
>>> ability.
>>>
>>> +1 for the release from me.
>>>
> I second that . The only thing I can mention is that even if manual
> installation procedure works for me , on the other hand all the
> attempts I made so as to install it from tarball in a Jenkins build
> job have failed . This is mainly because :
>
> 1. I'm not a proficient Jenkins user ...
> 2. it seems there's an issue with virtualenv somewhere and ...
> 3. I've not been able to dedicate any time to this task after the
> few initial experiments
>
> That's obviously not a reason to stop release tarball from being
> released , so ...
>
> +1 for release
>
>> The following is a short description of how to verify that the package
>> is signed:
>>
> [...]
>
> ... and all these checks , well I've not tried them yet . Should I ?
>
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
oops !
.. [1] Jenkins » bh-trac-test » #45 » Console Output
(http://hudson.testrun.org/job/bh-trac-test/45/console)
On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
> On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
>> On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
>>
> [...]
>>
>>> If you
>>> don't have an appropriate path for a local repository it probably is not
>>> worth specifying either option.
>>>
>>
>> I c ... I'll try again and let you know .
>
> bingo !
> works ok without repos options [1]_
> thnx !
> ;)
>
>> Nonetheless , afaics , that
>> should work due to the fact that those values are the ones used in
>> trac-admin initenv interactive console as well as trac.ini to specify
>> «no repository» .
>>
>
> I think maybe there's a chance to get this done for Release 2 ... ?
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 08/06/2012 03:50 AM, Olemis Lang wrote:
>> Nonetheless , afaics , that
>> should work due to the fact that those values are the ones used in
>> trac-admin initenv interactive console as well as trac.ini to specify
>> «no repository» .
>>
> I think maybe there's a chance to get this done for Release 2 ... ?
>
Well, as far as I can tell, no, this is not valid input to the
trac-admin initenv command and it requires both positional arguments.
As a bug, it may well get fixed for the next release. I'll probably just
make it silently drop any repo type specification when there is no path
specified.
For the other symmetric failure (no repo type specified but a path
provided), there may be a potential to detect what the repository type
is but for the moment I think I will choose failure with an informative
message.
Cheers,
Gary
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
> On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
>
[...]
>
>> If you
>> don't have an appropriate path for a local repository it probably is not
>> worth specifying either option.
>>
>
> I c ... I'll try again and let you know .
bingo !
works ok without repos options [1]_
thnx !
;)
> Nonetheless , afaics , that
> should work due to the fact that those values are the ones used in
> trac-admin initenv interactive console as well as trac.ini to specify
> «no repository» .
>
I think maybe there's a chance to get this done for Release 2 ... ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
> Hi Olemis,
>
:)
> Remember that my alteration to your patch meant that the positional
> arguments for an initenv remain unchanged so that should not be the issue.
>
you are right . I forgot
:-/
> I think I have spotted the most likely reason for the error you see.
> Although it is not clear what arguments you are passing to the
> bloodhound_setup.py,
it's something like this
{{{
#!python
call([python, 'bloodhound_setup.py',
'-d', 'sqlite',
'--admin-password=testrun', '--admin-user=bhadmin',
'--repository-type=svn', '--repository-path='],
cwd=folder_installer, env=ENVIRONMENT)
}}}
> I think you might be specifying either the
> repository type or repository path.
yes
> I see that the logic around that is
> a little suspect in that there is no check to see if only one of these
> is provided.
>
I'm supplying both but repository path is empty. That usually means
«no repository»
> I will add a check for that at some point but could you check if you
> pass either the --repository-type or --repository-path options.
yes , both
> If you
> don't have an appropriate path for a local repository it probably is not
> worth specifying either option.
>
I c ... I'll try again and let you know . Nonetheless , afaics , that
should work due to the fact that those values are the ones used in
trac-admin initenv interactive console as well as trac.ini to specify
«no repository» .
[...]
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
Hi Olemis,
Remember that my alteration to your patch meant that the positional
arguments for an initenv remain unchanged so that should not be the issue.
I think I have spotted the most likely reason for the error you see.
Although it is not clear what arguments you are passing to the
bloodhound_setup.py, I think you might be specifying either the
repository type or repository path. I see that the logic around that is
a little suspect in that there is no check to see if only one of these
is provided.
I will add a check for that at some point but could you check if you
pass either the --repository-type or --repository-path options. If you
don't have an appropriate path for a local repository it probably is not
worth specifying either option.
Cheers,
Gary
On 05/08/12 06:11, Olemis Lang wrote:
> u r a genius !
> That works for me too . Now all dependencies are installed
> :)
>
> Nonetheless , I noticed something is happening in there [1]_ . AFAICS
> an error is raised when Trac environment is created and installer
> configuration saved . Details follow
>
> {{{
> Successfully installed Babel BloodhoundDashboardPlugin
> BloodhoundMultiProduct BloodhoundTheme Genshi Pygments pytz Trac
> TracAccountManager TracPermRedirect TracThemeEngine
> Initenv for '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main'
> failed.
> Wrong number of arguments: 3
> Traceback (most recent call last):
> File "bloodhound_setup.py", line 379, in <module>
> bsetup.setup()
> File "bloodhound_setup.py", line 192, in setup
> self.writeconfig(baseini, [BASE_CONFIG, accounts_config])
> File "bloodhound_setup.py", line 242, in writeconfig
> config.save()
> File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/config.py",
> line 237, in save
> with AtomicFile(self.filename, 'w') as fileobj:
> File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/util/__init__.py",
> line 171, in __init__
> (fd, self._temp) = tempfile.mkstemp(prefix=name + '-', dir=dir)
> File "/usr/lib/python2.6/tempfile.py", line 293, in mkstemp
> return _mkstemp_inner(dir, prefix, suffix, flags)
> File "/usr/lib/python2.6/tempfile.py", line 228, in _mkstemp_inner
> fd = _os.open(file, flags, 0600)
> OSError: [Errno 2] No such file or directory:
> '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main/conf/base.ini-hUfPj7'
> }}}
>
> Considering the fact that there's no Trac environment at the moment ,
> it seems that the problem is related to the number of parameters
> supplied in to trac-admin command . I reviewed the code in console.py
> file (more precisely `TracAdmin.do_initenv` ) and it seems changes
> sketched in this patch [2]_ for #85 (... and enhanced later by Gary
> ...) have not been applied in trunk ?
>
> Could you please check ?
> This seems to be a critical bug afaics
>
> I'll setup something similar for the installer instead of svn co of trunk
>
> .. [1] Jenkins » bh-trac-test » #44 » Console Output
> (http://hudson.testrun.org/job/bh-trac-test/44/console)
>
> .. [2] Patch: BH Trac #85 : Option in trac-admin initenv cmd to
> prevent loading default wiki pages (optional)
> (https://issues.apache.org/bloodhound/attachment/ticket/85/t85_r1357341_initenv_nodocs.diff)
>
>
> On 8/3/12, Gary Martin <ga...@wandisco.com> wrote:
>> Greg,
>>
>> That is a good idea. I was thinking of possibly using buildbot to do
>> that job as well. Of course, if a dist script is created it can always
>> just call that instead so you idea probably provides the best basic
>> solution. I believe you did mention one release process script from
>> subversion so I will investigate that. Thanks.
>>
>> Olemis,
>>
>> My buildbot master.cfg needs a bit of redacting so I will try to fix
>> that and commit it to the repository for others to suggest improvements
>> by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
>> from my code:
>>
>> instdir = os.path.join("build", "installer")
>> env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
>> ":${PATH}",
>> 'PYTHONPATH':
>> os.path.abspath("build/installer/bloodhound/lib/python2.7")}
>> envdir = 'bloodhound'
>> pip = os.path.join(envdir, 'bin', 'pip')
>>
>> factory.addStep(ShellCommand(command=["virtualenv",
>> "--no-site-packages", envdir], workdir=instdir, name="install
>> virtualenv"))
>> factory.addStep(ShellCommand(command=[pip, 'install', '-r',
>> reqsfile], workdir=instdir, env=env, name="install packages"))
>> factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
>> '-d', 'sqlite',
>> '--admin-user=' + adminuser,
>> '--admin-password=' + adminpassword], workdir=instdir, name="setup"))
>>
>> steps after this were all tests of one sort or another followed by a
>> removal of the bloodhound directory for a bit of cleanup just in case
>> the buildslave is persistent.
>>
>> Cheers,
>> Gary
>>
>>
>> On 08/03/2012 07:31 AM, Greg Stein wrote:
>>> I'd also recommend creating a "dist.sh" script for assembling the
>>> tarball. For example, I queried if the wireframes should be
>>> distributed, and the answer was "no". That implies that assembling the
>>> tarball requires an "rm" step somewhere after the "svn export". It
>>> would be nice to script that, rather than following a list of manual
>>> steps.
>>>
>>> I believe that I've posted example dist.sh types of scripts, but would
>>> be happy to repost if needed.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>>>> could you share your build script , please ?
>>>>
>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>>>> technical
>>>>>>>> ability.
>>>>>>>>
>>>>>>>> +1 for the release from me.
>>>>>>>>
>>>>>> I second that . The only thing I can mention is that even if manual
>>>>>> installation procedure works for me , on the other hand all the
>>>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>>>> job have failed . This is mainly because :
>>>>>>
>>>>>> 1. I'm not a proficient Jenkins user ...
>>>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>>>> 3. I've not been able to dedicate any time to this task after the
>>>>>> few initial experiments
>>>>> I appear to have been able to get things going with Buildbot with the
>>>>> virtualenv instructions, although I am not convinced that you can
>>>>> really
>>>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>>>> resorted to a bit of trickery through which python binary was used
>>>>> after
>>>>> virtualenv creation.
>>>>>
>>>>> To be fair, there is no specific need to use virtualenv, as long as you
>>>>> have a fresh environment each time. My attempts so far have not been
>>>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>>>> to isolate a python environment.
>>>>>
>>>>> Cheers,
>>>>> Gary
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Olemis.
>>>>
>>>> Blog ES: http://simelo-es.blogspot.com/
>>>> Blog EN: http://simelo-en.blogspot.com/
>>>>
>>>> Featured article:
>>
>
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
u r a genius !
That works for me too . Now all dependencies are installed
:)
Nonetheless , I noticed something is happening in there [1]_ . AFAICS
an error is raised when Trac environment is created and installer
configuration saved . Details follow
{{{
Successfully installed Babel BloodhoundDashboardPlugin
BloodhoundMultiProduct BloodhoundTheme Genshi Pygments pytz Trac
TracAccountManager TracPermRedirect TracThemeEngine
Initenv for '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main'
failed.
Wrong number of arguments: 3
Traceback (most recent call last):
File "bloodhound_setup.py", line 379, in <module>
bsetup.setup()
File "bloodhound_setup.py", line 192, in setup
self.writeconfig(baseini, [BASE_CONFIG, accounts_config])
File "bloodhound_setup.py", line 242, in writeconfig
config.save()
File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/config.py",
line 237, in save
with AtomicFile(self.filename, 'w') as fileobj:
File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/util/__init__.py",
line 171, in __init__
(fd, self._temp) = tempfile.mkstemp(prefix=name + '-', dir=dir)
File "/usr/lib/python2.6/tempfile.py", line 293, in mkstemp
return _mkstemp_inner(dir, prefix, suffix, flags)
File "/usr/lib/python2.6/tempfile.py", line 228, in _mkstemp_inner
fd = _os.open(file, flags, 0600)
OSError: [Errno 2] No such file or directory:
'/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main/conf/base.ini-hUfPj7'
}}}
Considering the fact that there's no Trac environment at the moment ,
it seems that the problem is related to the number of parameters
supplied in to trac-admin command . I reviewed the code in console.py
file (more precisely `TracAdmin.do_initenv` ) and it seems changes
sketched in this patch [2]_ for #85 (... and enhanced later by Gary
...) have not been applied in trunk ?
Could you please check ?
This seems to be a critical bug afaics
I'll setup something similar for the installer instead of svn co of trunk
.. [1] Jenkins » bh-trac-test » #44 » Console Output
(http://hudson.testrun.org/job/bh-trac-test/44/console)
.. [2] Patch: BH Trac #85 : Option in trac-admin initenv cmd to
prevent loading default wiki pages (optional)
(https://issues.apache.org/bloodhound/attachment/ticket/85/t85_r1357341_initenv_nodocs.diff)
On 8/3/12, Gary Martin <ga...@wandisco.com> wrote:
> Greg,
>
> That is a good idea. I was thinking of possibly using buildbot to do
> that job as well. Of course, if a dist script is created it can always
> just call that instead so you idea probably provides the best basic
> solution. I believe you did mention one release process script from
> subversion so I will investigate that. Thanks.
>
> Olemis,
>
> My buildbot master.cfg needs a bit of redacting so I will try to fix
> that and commit it to the repository for others to suggest improvements
> by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
> from my code:
>
> instdir = os.path.join("build", "installer")
> env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
> ":${PATH}",
> 'PYTHONPATH':
> os.path.abspath("build/installer/bloodhound/lib/python2.7")}
> envdir = 'bloodhound'
> pip = os.path.join(envdir, 'bin', 'pip')
>
> factory.addStep(ShellCommand(command=["virtualenv",
> "--no-site-packages", envdir], workdir=instdir, name="install
> virtualenv"))
> factory.addStep(ShellCommand(command=[pip, 'install', '-r',
> reqsfile], workdir=instdir, env=env, name="install packages"))
> factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
> '-d', 'sqlite',
> '--admin-user=' + adminuser,
> '--admin-password=' + adminpassword], workdir=instdir, name="setup"))
>
> steps after this were all tests of one sort or another followed by a
> removal of the bloodhound directory for a bit of cleanup just in case
> the buildslave is persistent.
>
> Cheers,
> Gary
>
>
> On 08/03/2012 07:31 AM, Greg Stein wrote:
>> I'd also recommend creating a "dist.sh" script for assembling the
>> tarball. For example, I queried if the wireframes should be
>> distributed, and the answer was "no". That implies that assembling the
>> tarball requires an "rm" step somewhere after the "svn export". It
>> would be nice to script that, rather than following a list of manual
>> steps.
>>
>> I believe that I've posted example dist.sh types of scripts, but would
>> be happy to repost if needed.
>>
>> Cheers,
>> -g
>>
>> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>>> could you share your build script , please ?
>>>
>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>>> technical
>>>>>>> ability.
>>>>>>>
>>>>>>> +1 for the release from me.
>>>>>>>
>>>>> I second that . The only thing I can mention is that even if manual
>>>>> installation procedure works for me , on the other hand all the
>>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>>> job have failed . This is mainly because :
>>>>>
>>>>> 1. I'm not a proficient Jenkins user ...
>>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>>> 3. I've not been able to dedicate any time to this task after the
>>>>> few initial experiments
>>>> I appear to have been able to get things going with Buildbot with the
>>>> virtualenv instructions, although I am not convinced that you can
>>>> really
>>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>>> resorted to a bit of trickery through which python binary was used
>>>> after
>>>> virtualenv creation.
>>>>
>>>> To be fair, there is no specific need to use virtualenv, as long as you
>>>> have a fresh environment each time. My attempts so far have not been
>>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>>> to isolate a python environment.
>>>>
>>>> Cheers,
>>>> Gary
>>>>
>>>
>>> --
>>> Regards,
>>>
>>> Olemis.
>>>
>>> Blog ES: http://simelo-es.blogspot.com/
>>> Blog EN: http://simelo-en.blogspot.com/
>>>
>>> Featured article:
>
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
Greg,
That is a good idea. I was thinking of possibly using buildbot to do
that job as well. Of course, if a dist script is created it can always
just call that instead so you idea probably provides the best basic
solution. I believe you did mention one release process script from
subversion so I will investigate that. Thanks.
Olemis,
My buildbot master.cfg needs a bit of redacting so I will try to fix
that and commit it to the repository for others to suggest improvements
by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
from my code:
instdir = os.path.join("build", "installer")
env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
":${PATH}",
'PYTHONPATH':
os.path.abspath("build/installer/bloodhound/lib/python2.7")}
envdir = 'bloodhound'
pip = os.path.join(envdir, 'bin', 'pip')
factory.addStep(ShellCommand(command=["virtualenv",
"--no-site-packages", envdir], workdir=instdir, name="install
virtualenv"))
factory.addStep(ShellCommand(command=[pip, 'install', '-r',
reqsfile], workdir=instdir, env=env, name="install packages"))
factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
'-d', 'sqlite',
'--admin-user=' + adminuser,
'--admin-password=' + adminpassword], workdir=instdir, name="setup"))
steps after this were all tests of one sort or another followed by a
removal of the bloodhound directory for a bit of cleanup just in case
the buildslave is persistent.
Cheers,
Gary
On 08/03/2012 07:31 AM, Greg Stein wrote:
> I'd also recommend creating a "dist.sh" script for assembling the
> tarball. For example, I queried if the wireframes should be
> distributed, and the answer was "no". That implies that assembling the
> tarball requires an "rm" step somewhere after the "svn export". It
> would be nice to script that, rather than following a list of manual
> steps.
>
> I believe that I've posted example dist.sh types of scripts, but would
> be happy to repost if needed.
>
> Cheers,
> -g
>
> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>> could you share your build script , please ?
>>
>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>> technical
>>>>>> ability.
>>>>>>
>>>>>> +1 for the release from me.
>>>>>>
>>>> I second that . The only thing I can mention is that even if manual
>>>> installation procedure works for me , on the other hand all the
>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>> job have failed . This is mainly because :
>>>>
>>>> 1. I'm not a proficient Jenkins user ...
>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>> 3. I've not been able to dedicate any time to this task after the
>>>> few initial experiments
>>> I appear to have been able to get things going with Buildbot with the
>>> virtualenv instructions, although I am not convinced that you can really
>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>> resorted to a bit of trickery through which python binary was used after
>>> virtualenv creation.
>>>
>>> To be fair, there is no specific need to use virtualenv, as long as you
>>> have a fresh environment each time. My attempts so far have not been
>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>> to isolate a python environment.
>>>
>>> Cheers,
>>> Gary
>>>
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Greg Stein <gs...@gmail.com>.
I'd also recommend creating a "dist.sh" script for assembling the
tarball. For example, I queried if the wireframes should be
distributed, and the answer was "no". That implies that assembling the
tarball requires an "rm" step somewhere after the "svn export". It
would be nice to script that, rather than following a list of manual
steps.
I believe that I've posted example dist.sh types of scripts, but would
be happy to repost if needed.
Cheers,
-g
On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
> could you share your build script , please ?
>
> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>
>> On 02/08/12 01:57, Olemis Lang wrote:
>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>> technical
>>>>> ability.
>>>>>
>>>>> +1 for the release from me.
>>>>>
>>> I second that . The only thing I can mention is that even if manual
>>> installation procedure works for me , on the other hand all the
>>> attempts I made so as to install it from tarball in a Jenkins build
>>> job have failed . This is mainly because :
>>>
>>> 1. I'm not a proficient Jenkins user ...
>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>> 3. I've not been able to dedicate any time to this task after the
>>> few initial experiments
>>
>> I appear to have been able to get things going with Buildbot with the
>> virtualenv instructions, although I am not convinced that you can really
>> activate the virtualenv in a buildstep. I didn't try this and instead
>> resorted to a bit of trickery through which python binary was used after
>> virtualenv creation.
>>
>> To be fair, there is no specific need to use virtualenv, as long as you
>> have a fresh environment each time. My attempts so far have not been
>> with throwaway VMs. Of course, I am sure that there will be other ways
>> to isolate a python environment.
>>
>> Cheers,
>> Gary
>>
>
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
could you share your build script , please ?
On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>
> On 02/08/12 01:57, Olemis Lang wrote:
>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>> Just for the record, I have downloaded reviewed the files to my
>>>> technical
>>>> ability.
>>>>
>>>> +1 for the release from me.
>>>>
>> I second that . The only thing I can mention is that even if manual
>> installation procedure works for me , on the other hand all the
>> attempts I made so as to install it from tarball in a Jenkins build
>> job have failed . This is mainly because :
>>
>> 1. I'm not a proficient Jenkins user ...
>> 2. it seems there's an issue with virtualenv somewhere and ...
>> 3. I've not been able to dedicate any time to this task after the
>> few initial experiments
>
> I appear to have been able to get things going with Buildbot with the
> virtualenv instructions, although I am not convinced that you can really
> activate the virtualenv in a buildstep. I didn't try this and instead
> resorted to a bit of trickery through which python binary was used after
> virtualenv creation.
>
> To be fair, there is no specific need to use virtualenv, as long as you
> have a fresh environment each time. My attempts so far have not been
> with throwaway VMs. Of course, I am sure that there will be other ways
> to isolate a python environment.
>
> Cheers,
> Gary
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound 0.1.0
(incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 02/08/12 01:57, Olemis Lang wrote:
> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>> Just for the record, I have downloaded reviewed the files to my technical
>>> ability.
>>>
>>> +1 for the release from me.
>>>
> I second that . The only thing I can mention is that even if manual
> installation procedure works for me , on the other hand all the
> attempts I made so as to install it from tarball in a Jenkins build
> job have failed . This is mainly because :
>
> 1. I'm not a proficient Jenkins user ...
> 2. it seems there's an issue with virtualenv somewhere and ...
> 3. I've not been able to dedicate any time to this task after the
> few initial experiments
I appear to have been able to get things going with Buildbot with the
virtualenv instructions, although I am not convinced that you can really
activate the virtualenv in a buildstep. I didn't try this and instead
resorted to a bit of trickery through which python binary was used after
virtualenv creation.
To be fair, there is no specific need to use virtualenv, as long as you
have a fresh environment each time. My attempts so far have not been
with throwaway VMs. Of course, I am sure that there will be other ways
to isolate a python environment.
Cheers,
Gary
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
> On 30/07/12 12:48, Joachim Dreimann wrote:
>> Just for the record, I have downloaded reviewed the files to my technical
>> ability.
>>
>> +1 for the release from me.
>>
I second that . The only thing I can mention is that even if manual
installation procedure works for me , on the other hand all the
attempts I made so as to install it from tarball in a Jenkins build
job have failed . This is mainly because :
1. I'm not a proficient Jenkins user ...
2. it seems there's an issue with virtualenv somewhere and ...
3. I've not been able to dedicate any time to this task after the
few initial experiments
That's obviously not a reason to stop release tarball from being
released , so ...
+1 for release
>
> The following is a short description of how to verify that the package
> is signed:
>
[...]
... and all these checks , well I've not tried them yet . Should I ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Thanks Joe, that is very much appreciated.
I would also plus one on this vote although I am not sure it would be
better to get our binding votes from three people independently of the
release manager and, in particular, with the help of our mentors. In
fact, I was under the impression that the support of our mentors was
pretty much essential.
For those who are less experienced, is there anything you need to know
about the process to help you decide on your vote?
The following is a short description of how to verify that the package
is signed:
http://www.apache.org/dev/release-signing.html#verifying-signature
In summary if you checkout the whole of
https://dist.apache.org/repos/dist/dev/incubator/bloodhound/ there is a
KEYS file, the
signature file, the release tarball itself, allowing you to:
|gpg --import KEYS
||gpg --verify apache-bloodhound-incubating-0.1.0-RC1.tar.gz.asc||apache-bloodhound-incubating-0.1.0-RC1.tar.gz|||
There is also an md5 file if you wish to verify that against the tarball
too.
Apache Rat, meanwhile, may provide a way to determine what files are
missing apache licence headers. If you are interested in using that,
details can be found here: http://creadur.apache.org/rat/
Cheers,
Gary
On 30/07/12 12:48, Joachim Dreimann wrote:
> Just for the record, I have downloaded reviewed the files to my technical
> ability.
>
> +1 for the release from me.
>
> Cheers,
> Joe
>
> On 30 July 2012 10:49, Gary Martin <ga...@wandisco.com> wrote:
>
>> Hi,
>>
>> The 72 hours is well past and so it looks like I have failed to mobilise
>> the potential vote at this point. I have not looked up the rules associated
>> with votes that are past their sell-by date, but for now I am prepared to
>> let the vote continue.
>>
>> In case I haven't mentioned this before, I am particularly interested in
>> the votes of our mentors. Sorry for any pressure that this puts upon them
>> but If there are any problems with eligibility for release, I am sure they
>> will spot them.
>>
>> Cheers,
>> Gary
>>
>>
>>
>> On 25/07/12 21:36, Greg Stein wrote:
>>
>>> Here are the instructions that Subversion uses, so it would be
>>> something similar:
>>> http://subversion.apache.org/**docs/community-guide/**
>>> releasing.html#tarball-signing<http://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing>
>>>
>>> You can see the resulting set of signatures for each tarball; for example:
>>> https://dist.apache.org/repos/**dist/release/subversion/**
>>> subversion-1.7.5.tar.bz2.asc<https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.5.tar.bz2.asc>
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Jul 25, 2012 at 4:19 PM, Mark Poole <mp...@apache.org> wrote:
>>>
>>>> I'm currently running this version in production.
>>>>
>>>> How would I provide you with my signature to verify the release in
>>>> future?
>>>>
>>>> On Wed, Jul 25, 2012 at 7:33 PM, Greg Stein <gs...@gmail.com> wrote:
>>>>
>>>> PPMC members have a "binding" vote (ie. it counts).
>>>>> All others can vote, but those are considered advisory or "non-binding".
>>>>>
>>>>> People should vote +1 *only* if they have downloaded the tarball and
>>>>> reviewed it. Including verification of signature(s). In the future, it
>>>>> would be nice to get additional signatures from those who vote +1, and
>>>>> attach those signatures to the release.
>>>>>
>>>>> Cheers,
>>>>> -g
>>>>>
>>>>> On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com>
>>>>> wrote:
>>>>>
>>>>>> Great to see!
>>>>>>
>>>>>> Who can vote?
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> --
>>>>>> Ian Wild
>>>>>> VP Engineering
>>>>>> WANdisco plc
>>>>>>
>>>>>> Mobile +44 (0)7720 093010
>>>>>> Office DDI: +44 (0)114 3030472
>>>>>> US: +1 925 3801734
>>>>>>
>>>>>> http://www.wandisco.com
>>>>>>
>>>>>> uberSVN: Apache Subversion Made Easy
>>>>>> http://www.uberSVN.com <http://www.ubersvn.com/>
>>>>>>
>>>>>> Everything you need to deploy Subversion in the Enterprise
>>>>>> http://www.wandisco.com/**subversion<http://www.wandisco.com/subversion>
>>>>>> <
>>>>>>
>>>>> http://www.wandisco.com/**subversion/multisite<http://www.wandisco.com/subversion/multisite>
>>>>>> Subversion community
>>>>>> http://www.svnforum.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <gary.martin@wandisco.com
>>>>>> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>> I hope that this is not premature but as the conversation on the
>>>>>>> related
>>>>>>> [PROPOSAL] thread has died down, I would like to initiate the vote for
>>>>>>> releasing Apache Bloodhound 0.1.0 (incubating). If successful this
>>>>>>> will
>>>>>>>
>>>>>> be
>>>>>> the first release of the project and is an important step that I hope
>>>>>> will
>>>>>> generate interest in the project and help the community to grow.
>>>>>>> The release candidate this vote relates to provides:
>>>>>>>
>>>>>>> * A patched version of Trac
>>>>>>> * A new dashboard view with the dashboard style unifying views of
>>>>>>> tickets, milestones and the user's dashboard.
>>>>>>> * A re-theming of the interface to use bootstrap
>>>>>>> * Preliminary multi-product support as a step towards allowing the
>>>>>>> tracking of multiple distinct products (or projects) in a single
>>>>>>> environment
>>>>>>> * Simplified installation with the inclusion of a number of plugins
>>>>>>> as
>>>>>>> standard.
>>>>>>>
>>>>>>> As an initial release, of particular importance is that we have taken
>>>>>>> proper notice of licensing of code produced as part of this project
>>>>>>> and
>>>>>>>
>>>>>> the
>>>>>> proper acknowledgement of external work packaged with it.
>>>>>>> The release candidate artifacts consist of source release as a tar.gz
>>>>>>> archive along with the associated MD5 and GPG signature. These can be
>>>>>>>
>>>>>> found
>>>>>> at: https://dist.apache.org/repos/****dist/dev/incubator/**bloodhound/<https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/>
>>>>>>> <
>>>>>>>
>>>>>> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>>>> **>
>>>>>
>>>>>> Please vote:
>>>>>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>>>>>> [ ] +0 Don't care
>>>>>>> [ ] -1 Do not release this package (please explain)
>>>>>>>
>>>>>>> The vote is open for 72 hours and, if successful, will be followed by
>>>>>>> a
>>>>>>> vote on general@incubator for a further 72 hours.
>>>>>>>
>>>>>>>
>>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Joachim Dreimann <jo...@wandisco.com>.
Just for the record, I have downloaded reviewed the files to my technical
ability.
+1 for the release from me.
Cheers,
Joe
On 30 July 2012 10:49, Gary Martin <ga...@wandisco.com> wrote:
> Hi,
>
> The 72 hours is well past and so it looks like I have failed to mobilise
> the potential vote at this point. I have not looked up the rules associated
> with votes that are past their sell-by date, but for now I am prepared to
> let the vote continue.
>
> In case I haven't mentioned this before, I am particularly interested in
> the votes of our mentors. Sorry for any pressure that this puts upon them
> but If there are any problems with eligibility for release, I am sure they
> will spot them.
>
> Cheers,
> Gary
>
>
>
> On 25/07/12 21:36, Greg Stein wrote:
>
>> Here are the instructions that Subversion uses, so it would be
>> something similar:
>> http://subversion.apache.org/**docs/community-guide/**
>> releasing.html#tarball-signing<http://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing>
>>
>> You can see the resulting set of signatures for each tarball; for example:
>> https://dist.apache.org/repos/**dist/release/subversion/**
>> subversion-1.7.5.tar.bz2.asc<https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.5.tar.bz2.asc>
>>
>> Cheers,
>> -g
>>
>> On Wed, Jul 25, 2012 at 4:19 PM, Mark Poole <mp...@apache.org> wrote:
>>
>>> I'm currently running this version in production.
>>>
>>> How would I provide you with my signature to verify the release in
>>> future?
>>>
>>> On Wed, Jul 25, 2012 at 7:33 PM, Greg Stein <gs...@gmail.com> wrote:
>>>
>>> PPMC members have a "binding" vote (ie. it counts).
>>>>
>>>> All others can vote, but those are considered advisory or "non-binding".
>>>>
>>>> People should vote +1 *only* if they have downloaded the tarball and
>>>> reviewed it. Including verification of signature(s). In the future, it
>>>> would be nice to get additional signatures from those who vote +1, and
>>>> attach those signatures to the release.
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>>> On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com>
>>>> wrote:
>>>>
>>>>> Great to see!
>>>>>
>>>>> Who can vote?
>>>>>
>>>>> Ian
>>>>>
>>>>> --
>>>>> Ian Wild
>>>>> VP Engineering
>>>>> WANdisco plc
>>>>>
>>>>> Mobile +44 (0)7720 093010
>>>>> Office DDI: +44 (0)114 3030472
>>>>> US: +1 925 3801734
>>>>>
>>>>> http://www.wandisco.com
>>>>>
>>>>> uberSVN: Apache Subversion Made Easy
>>>>> http://www.uberSVN.com <http://www.ubersvn.com/>
>>>>>
>>>>> Everything you need to deploy Subversion in the Enterprise
>>>>> http://www.wandisco.com/**subversion<http://www.wandisco.com/subversion>
>>>>> <
>>>>>
>>>> http://www.wandisco.com/**subversion/multisite<http://www.wandisco.com/subversion/multisite>
>>>> >
>>>>
>>>>> Subversion community
>>>>> http://www.svnforum.org
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <gary.martin@wandisco.com
>>>>> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>>
>>>>>> I hope that this is not premature but as the conversation on the
>>>>>> related
>>>>>> [PROPOSAL] thread has died down, I would like to initiate the vote for
>>>>>> releasing Apache Bloodhound 0.1.0 (incubating). If successful this
>>>>>> will
>>>>>>
>>>>> be
>>>>
>>>>> the first release of the project and is an important step that I hope
>>>>>>
>>>>> will
>>>>
>>>>> generate interest in the project and help the community to grow.
>>>>>>
>>>>>> The release candidate this vote relates to provides:
>>>>>>
>>>>>> * A patched version of Trac
>>>>>> * A new dashboard view with the dashboard style unifying views of
>>>>>> tickets, milestones and the user's dashboard.
>>>>>> * A re-theming of the interface to use bootstrap
>>>>>> * Preliminary multi-product support as a step towards allowing the
>>>>>> tracking of multiple distinct products (or projects) in a single
>>>>>> environment
>>>>>> * Simplified installation with the inclusion of a number of plugins
>>>>>> as
>>>>>> standard.
>>>>>>
>>>>>> As an initial release, of particular importance is that we have taken
>>>>>> proper notice of licensing of code produced as part of this project
>>>>>> and
>>>>>>
>>>>> the
>>>>
>>>>> proper acknowledgement of external work packaged with it.
>>>>>>
>>>>>> The release candidate artifacts consist of source release as a tar.gz
>>>>>> archive along with the associated MD5 and GPG signature. These can be
>>>>>>
>>>>> found
>>>>
>>>>> at: https://dist.apache.org/repos/****dist/dev/incubator/**bloodhound/<https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/>
>>>>>> <
>>>>>>
>>>>> https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>>> **>
>>>>
>>>>> Please vote:
>>>>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>>>>> [ ] +0 Don't care
>>>>>> [ ] -1 Do not release this package (please explain)
>>>>>>
>>>>>> The vote is open for 72 hours and, if successful, will be followed by
>>>>>> a
>>>>>> vote on general@incubator for a further 72 hours.
>>>>>>
>>>>>>
>
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Hi,
The 72 hours is well past and so it looks like I have failed to mobilise
the potential vote at this point. I have not looked up the rules
associated with votes that are past their sell-by date, but for now I am
prepared to let the vote continue.
In case I haven't mentioned this before, I am particularly interested in
the votes of our mentors. Sorry for any pressure that this puts upon
them but If there are any problems with eligibility for release, I am
sure they will spot them.
Cheers,
Gary
On 25/07/12 21:36, Greg Stein wrote:
> Here are the instructions that Subversion uses, so it would be
> something similar:
> http://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing
>
> You can see the resulting set of signatures for each tarball; for example:
> https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.5.tar.bz2.asc
>
> Cheers,
> -g
>
> On Wed, Jul 25, 2012 at 4:19 PM, Mark Poole <mp...@apache.org> wrote:
>> I'm currently running this version in production.
>>
>> How would I provide you with my signature to verify the release in future?
>>
>> On Wed, Jul 25, 2012 at 7:33 PM, Greg Stein <gs...@gmail.com> wrote:
>>
>>> PPMC members have a "binding" vote (ie. it counts).
>>>
>>> All others can vote, but those are considered advisory or "non-binding".
>>>
>>> People should vote +1 *only* if they have downloaded the tarball and
>>> reviewed it. Including verification of signature(s). In the future, it
>>> would be nice to get additional signatures from those who vote +1, and
>>> attach those signatures to the release.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com> wrote:
>>>> Great to see!
>>>>
>>>> Who can vote?
>>>>
>>>> Ian
>>>>
>>>> --
>>>> Ian Wild
>>>> VP Engineering
>>>> WANdisco plc
>>>>
>>>> Mobile +44 (0)7720 093010
>>>> Office DDI: +44 (0)114 3030472
>>>> US: +1 925 3801734
>>>>
>>>> http://www.wandisco.com
>>>>
>>>> uberSVN: Apache Subversion Made Easy
>>>> http://www.uberSVN.com <http://www.ubersvn.com/>
>>>>
>>>> Everything you need to deploy Subversion in the Enterprise
>>>> http://www.wandisco.com/subversion<
>>> http://www.wandisco.com/subversion/multisite>
>>>> Subversion community
>>>> http://www.svnforum.org
>>>>
>>>>
>>>>
>>>> On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <gary.martin@wandisco.com
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I hope that this is not premature but as the conversation on the related
>>>>> [PROPOSAL] thread has died down, I would like to initiate the vote for
>>>>> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will
>>> be
>>>>> the first release of the project and is an important step that I hope
>>> will
>>>>> generate interest in the project and help the community to grow.
>>>>>
>>>>> The release candidate this vote relates to provides:
>>>>>
>>>>> * A patched version of Trac
>>>>> * A new dashboard view with the dashboard style unifying views of
>>>>> tickets, milestones and the user's dashboard.
>>>>> * A re-theming of the interface to use bootstrap
>>>>> * Preliminary multi-product support as a step towards allowing the
>>>>> tracking of multiple distinct products (or projects) in a single
>>>>> environment
>>>>> * Simplified installation with the inclusion of a number of plugins as
>>>>> standard.
>>>>>
>>>>> As an initial release, of particular importance is that we have taken
>>>>> proper notice of licensing of code produced as part of this project and
>>> the
>>>>> proper acknowledgement of external work packaged with it.
>>>>>
>>>>> The release candidate artifacts consist of source release as a tar.gz
>>>>> archive along with the associated MD5 and GPG signature. These can be
>>> found
>>>>> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<
>>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>>>> Please vote:
>>>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>>>> [ ] +0 Don't care
>>>>> [ ] -1 Do not release this package (please explain)
>>>>>
>>>>> The vote is open for 72 hours and, if successful, will be followed by a
>>>>> vote on general@incubator for a further 72 hours.
>>>>>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
Here are the instructions that Subversion uses, so it would be
something similar:
http://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing
You can see the resulting set of signatures for each tarball; for example:
https://dist.apache.org/repos/dist/release/subversion/subversion-1.7.5.tar.bz2.asc
Cheers,
-g
On Wed, Jul 25, 2012 at 4:19 PM, Mark Poole <mp...@apache.org> wrote:
> I'm currently running this version in production.
>
> How would I provide you with my signature to verify the release in future?
>
> On Wed, Jul 25, 2012 at 7:33 PM, Greg Stein <gs...@gmail.com> wrote:
>
>> PPMC members have a "binding" vote (ie. it counts).
>>
>> All others can vote, but those are considered advisory or "non-binding".
>>
>> People should vote +1 *only* if they have downloaded the tarball and
>> reviewed it. Including verification of signature(s). In the future, it
>> would be nice to get additional signatures from those who vote +1, and
>> attach those signatures to the release.
>>
>> Cheers,
>> -g
>>
>> On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com> wrote:
>> > Great to see!
>> >
>> > Who can vote?
>> >
>> > Ian
>> >
>> > --
>> > Ian Wild
>> > VP Engineering
>> > WANdisco plc
>> >
>> > Mobile +44 (0)7720 093010
>> > Office DDI: +44 (0)114 3030472
>> > US: +1 925 3801734
>> >
>> > http://www.wandisco.com
>> >
>> > uberSVN: Apache Subversion Made Easy
>> > http://www.uberSVN.com <http://www.ubersvn.com/>
>> >
>> > Everything you need to deploy Subversion in the Enterprise
>> > http://www.wandisco.com/subversion<
>> http://www.wandisco.com/subversion/multisite>
>> >
>> > Subversion community
>> > http://www.svnforum.org
>> >
>> >
>> >
>> > On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <gary.martin@wandisco.com
>> >wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> I hope that this is not premature but as the conversation on the related
>> >> [PROPOSAL] thread has died down, I would like to initiate the vote for
>> >> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will
>> be
>> >> the first release of the project and is an important step that I hope
>> will
>> >> generate interest in the project and help the community to grow.
>> >>
>> >> The release candidate this vote relates to provides:
>> >>
>> >> * A patched version of Trac
>> >> * A new dashboard view with the dashboard style unifying views of
>> >> tickets, milestones and the user's dashboard.
>> >> * A re-theming of the interface to use bootstrap
>> >> * Preliminary multi-product support as a step towards allowing the
>> >> tracking of multiple distinct products (or projects) in a single
>> >> environment
>> >> * Simplified installation with the inclusion of a number of plugins as
>> >> standard.
>> >>
>> >> As an initial release, of particular importance is that we have taken
>> >> proper notice of licensing of code produced as part of this project and
>> the
>> >> proper acknowledgement of external work packaged with it.
>> >>
>> >> The release candidate artifacts consist of source release as a tar.gz
>> >> archive along with the associated MD5 and GPG signature. These can be
>> found
>> >> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<
>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>> >>
>> >> Please vote:
>> >> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> >> [ ] +0 Don't care
>> >> [ ] -1 Do not release this package (please explain)
>> >>
>> >> The vote is open for 72 hours and, if successful, will be followed by a
>> >> vote on general@incubator for a further 72 hours.
>> >>
>>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Mark Poole <mp...@apache.org>.
I'm currently running this version in production.
How would I provide you with my signature to verify the release in future?
On Wed, Jul 25, 2012 at 7:33 PM, Greg Stein <gs...@gmail.com> wrote:
> PPMC members have a "binding" vote (ie. it counts).
>
> All others can vote, but those are considered advisory or "non-binding".
>
> People should vote +1 *only* if they have downloaded the tarball and
> reviewed it. Including verification of signature(s). In the future, it
> would be nice to get additional signatures from those who vote +1, and
> attach those signatures to the release.
>
> Cheers,
> -g
>
> On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com> wrote:
> > Great to see!
> >
> > Who can vote?
> >
> > Ian
> >
> > --
> > Ian Wild
> > VP Engineering
> > WANdisco plc
> >
> > Mobile +44 (0)7720 093010
> > Office DDI: +44 (0)114 3030472
> > US: +1 925 3801734
> >
> > http://www.wandisco.com
> >
> > uberSVN: Apache Subversion Made Easy
> > http://www.uberSVN.com <http://www.ubersvn.com/>
> >
> > Everything you need to deploy Subversion in the Enterprise
> > http://www.wandisco.com/subversion<
> http://www.wandisco.com/subversion/multisite>
> >
> > Subversion community
> > http://www.svnforum.org
> >
> >
> >
> > On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <gary.martin@wandisco.com
> >wrote:
> >
> >> Hi everyone,
> >>
> >> I hope that this is not premature but as the conversation on the related
> >> [PROPOSAL] thread has died down, I would like to initiate the vote for
> >> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will
> be
> >> the first release of the project and is an important step that I hope
> will
> >> generate interest in the project and help the community to grow.
> >>
> >> The release candidate this vote relates to provides:
> >>
> >> * A patched version of Trac
> >> * A new dashboard view with the dashboard style unifying views of
> >> tickets, milestones and the user's dashboard.
> >> * A re-theming of the interface to use bootstrap
> >> * Preliminary multi-product support as a step towards allowing the
> >> tracking of multiple distinct products (or projects) in a single
> >> environment
> >> * Simplified installation with the inclusion of a number of plugins as
> >> standard.
> >>
> >> As an initial release, of particular importance is that we have taken
> >> proper notice of licensing of code produced as part of this project and
> the
> >> proper acknowledgement of external work packaged with it.
> >>
> >> The release candidate artifacts consist of source release as a tar.gz
> >> archive along with the associated MD5 and GPG signature. These can be
> found
> >> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<
> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
> >>
> >> Please vote:
> >> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> >> [ ] +0 Don't care
> >> [ ] -1 Do not release this package (please explain)
> >>
> >> The vote is open for 72 hours and, if successful, will be followed by a
> >> vote on general@incubator for a further 72 hours.
> >>
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
PPMC members have a "binding" vote (ie. it counts).
All others can vote, but those are considered advisory or "non-binding".
People should vote +1 *only* if they have downloaded the tarball and
reviewed it. Including verification of signature(s). In the future, it
would be nice to get additional signatures from those who vote +1, and
attach those signatures to the release.
Cheers,
-g
On Wed, Jul 25, 2012 at 1:19 PM, Ian Wild <ia...@wandisco.com> wrote:
> Great to see!
>
> Who can vote?
>
> Ian
>
> --
> Ian Wild
> VP Engineering
> WANdisco plc
>
> Mobile +44 (0)7720 093010
> Office DDI: +44 (0)114 3030472
> US: +1 925 3801734
>
> http://www.wandisco.com
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com <http://www.ubersvn.com/>
>
> Everything you need to deploy Subversion in the Enterprise
> http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>
>
> Subversion community
> http://www.svnforum.org
>
>
>
> On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <ga...@wandisco.com>wrote:
>
>> Hi everyone,
>>
>> I hope that this is not premature but as the conversation on the related
>> [PROPOSAL] thread has died down, I would like to initiate the vote for
>> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
>> the first release of the project and is an important step that I hope will
>> generate interest in the project and help the community to grow.
>>
>> The release candidate this vote relates to provides:
>>
>> * A patched version of Trac
>> * A new dashboard view with the dashboard style unifying views of
>> tickets, milestones and the user's dashboard.
>> * A re-theming of the interface to use bootstrap
>> * Preliminary multi-product support as a step towards allowing the
>> tracking of multiple distinct products (or projects) in a single
>> environment
>> * Simplified installation with the inclusion of a number of plugins as
>> standard.
>>
>> As an initial release, of particular importance is that we have taken
>> proper notice of licensing of code produced as part of this project and the
>> proper acknowledgement of external work packaged with it.
>>
>> The release candidate artifacts consist of source release as a tar.gz
>> archive along with the associated MD5 and GPG signature. These can be found
>> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>>
>> Please vote:
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>>
>> The vote is open for 72 hours and, if successful, will be followed by a
>> vote on general@incubator for a further 72 hours.
>>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Ian Wild <ia...@wandisco.com>.
Great to see!
Who can vote?
Ian
--
Ian Wild
VP Engineering
WANdisco plc
Mobile +44 (0)7720 093010
Office DDI: +44 (0)114 3030472
US: +1 925 3801734
http://www.wandisco.com
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>
Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>
Subversion community
http://www.svnforum.org
On Wed, Jul 25, 2012 at 6:18 PM, Gary Martin <ga...@wandisco.com>wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the related
> [PROPOSAL] thread has died down, I would like to initiate the vote for
> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
> the first release of the project and is an important step that I hope will
> generate interest in the project and help the community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins as
> standard.
>
> As an initial release, of particular importance is that we have taken
> proper notice of licensing of code produced as part of this project and the
> proper acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be found
> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by a
> vote on general@incubator for a further 72 hours.
>
Re: Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
At least in headers in bootstrap-*.js files I read
/* ==========================================================
* bootstrap-affix.js v2.1.0
* http://twitter.github.com/bootstrap/javascript.html#affix
* ==========================================================
* Copyright 2012 Twitter, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
* ========================================================== */
... short header in css files though ...
On 8/28/12, Gary Martin <ga...@wandisco.com> wrote:
> On 08/28/2012 02:45 PM, Branko Čibej wrote:
>> On 28.08.2012 15:31, Gary Martin wrote:
>>> On 08/28/2012 02:11 PM, Branko Čibej wrote:
>>>> On 28.08.2012 15:01, Gary Martin wrote:
>>>>> Bootstrap - licensed under the APLv2 License
>>>> What is the APLv2 License? You don't have to copy typos from the
>>>> Bootstrap authors. :)
>>>>
>>>> It's "the Apache License, version 2", same as for Bloodhound.
>>>>
>>>> -- Brane
>>>>
>>> Heh.. sorry. My typo.
>> The typo appears in Bootstrap's GitHub logs related to their LICENSE
>> file. The file itself appears to be the original ALv2 as published on
>> the Apache site. Haven't run a diff, though; it might not be too bad an
>> idea to do that.
>>
>> -- Brane
>>
>
> Oh, well, I didn't check to see if they had also made that mistake.. I
> am only saying that I did not copy the mistake from them as I was
> avoiding writing the whole thing out. I will try to be more careful in
> future.
>
> Other than that, I assume that Bootstrap's typo do not cause us any
> problem. From a quick look around the download, they sometimes only
> mentioning http://www.apache.org/licenses/LICENSE-2.0.txt but there are
> cases of mentioning Apache License v2.0 and Apache License, version 2.0.
> I cannot see their intent being questioned here but, as we are committed
> to attempting to get as close to perfection as possible with our
> compliance with any licensing issues, I am happy to take some time to
> look at this further if necessary.
>
> Anyway, I think I may as well make the changes I mentioned at the
> beginning of the thread (hopefully without any more typos) and see what
> happens.
>
> Cheers,
> Gary
>
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 08/28/2012 02:45 PM, Branko Čibej wrote:
> On 28.08.2012 15:31, Gary Martin wrote:
>> On 08/28/2012 02:11 PM, Branko Čibej wrote:
>>> On 28.08.2012 15:01, Gary Martin wrote:
>>>> Bootstrap - licensed under the APLv2 License
>>> What is the APLv2 License? You don't have to copy typos from the
>>> Bootstrap authors. :)
>>>
>>> It's "the Apache License, version 2", same as for Bloodhound.
>>>
>>> -- Brane
>>>
>> Heh.. sorry. My typo.
> The typo appears in Bootstrap's GitHub logs related to their LICENSE
> file. The file itself appears to be the original ALv2 as published on
> the Apache site. Haven't run a diff, though; it might not be too bad an
> idea to do that.
>
> -- Brane
>
Oh, well, I didn't check to see if they had also made that mistake.. I
am only saying that I did not copy the mistake from them as I was
avoiding writing the whole thing out. I will try to be more careful in
future.
Other than that, I assume that Bootstrap's typo do not cause us any
problem. From a quick look around the download, they sometimes only
mentioning http://www.apache.org/licenses/LICENSE-2.0.txt but there are
cases of mentioning Apache License v2.0 and Apache License, version 2.0.
I cannot see their intent being questioned here but, as we are committed
to attempting to get as close to perfection as possible with our
compliance with any licensing issues, I am happy to take some time to
look at this further if necessary.
Anyway, I think I may as well make the changes I mentioned at the
beginning of the thread (hopefully without any more typos) and see what
happens.
Cheers,
Gary
Re: Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Branko Čibej <br...@wandisco.com>.
On 28.08.2012 15:31, Gary Martin wrote:
> On 08/28/2012 02:11 PM, Branko Čibej wrote:
>> On 28.08.2012 15:01, Gary Martin wrote:
>>> Bootstrap - licensed under the APLv2 License
>> What is the APLv2 License? You don't have to copy typos from the
>> Bootstrap authors. :)
>>
>> It's "the Apache License, version 2", same as for Bloodhound.
>>
>> -- Brane
>>
>
> Heh.. sorry. My typo.
The typo appears in Bootstrap's GitHub logs related to their LICENSE
file. The file itself appears to be the original ALv2 as published on
the Apache site. Haven't run a diff, though; it might not be too bad an
idea to do that.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 08/28/2012 02:11 PM, Branko Čibej wrote:
> On 28.08.2012 15:01, Gary Martin wrote:
>> Bootstrap - licensed under the APLv2 License
> What is the APLv2 License? You don't have to copy typos from the
> Bootstrap authors. :)
>
> It's "the Apache License, version 2", same as for Bloodhound.
>
> -- Brane
>
Heh.. sorry. My typo.
Re: Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Branko Čibej <br...@wandisco.com>.
On 28.08.2012 15:01, Gary Martin wrote:
> Bootstrap - licensed under the APLv2 License
What is the APLv2 License? You don't have to copy typos from the
Bootstrap authors. :)
It's "the Apache License, version 2", same as for Bloodhound.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Change to NOTICE file? (Was Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 08/03/2012 09:26 AM, Greg Stein wrote:
> On Aug 3, 2012 4:15 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>> ...
>>>> NOTICE , LICENSE and other files will only need to
>>>> mention that file (<= I'm hoping we can do that).
>>> There is no need for these files to refer to a proposed TRAC_VERSION
>>> file. It is sufficient to state "portions developed by..." (as they do
>>> now).
>> I said so in order to say something like this in e.g. NOTICE file .
>>
>> "A modified copy of Trac is included in this source release package.
>> Exact version of Trac may be found in TRAC_VERSION file" ... etc , etc
> Ooooh... I like that! +1
>
> Cheers,
> -g
>
Given that this was liked...
At the moment the NOTICE file states:
Trac - licensed under the BSD License
This product include software (Trac) developed by
Edgewall Software (http://trac.edgewall.org/)
Are we happy with fixing the typo in the above and appending the
following to the trac section of the NOTICE file:
A modified copy of Trac is included in this source
release package. The exact version of Trac may be
found in the trac/TRAC_VERSION file.
It might also be nice for the bootstrap part of the NOTICE file to be
consistent with the rest - I think it should read:
Bootstrap - licensed under the APLv2 License
This product includes software (bootstrap) developed by
Twitter (http://twitter.github.com/bootstrap/)
to specify the license we understand it to use more carefully.
Cheers,
Gary
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 3, 2012 4:15 AM, "Olemis Lang" <ol...@gmail.com> wrote:
>...
> >> NOTICE , LICENSE and other files will only need to
> >> mention that file (<= I'm hoping we can do that).
> >
> > There is no need for these files to refer to a proposed TRAC_VERSION
> > file. It is sufficient to state "portions developed by..." (as they do
> > now).
>
> I said so in order to say something like this in e.g. NOTICE file .
>
> "A modified copy of Trac is included in this source release package.
> Exact version of Trac may be found in TRAC_VERSION file" ... etc , etc
Ooooh... I like that! +1
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
On 8/3/12, Greg Stein <gs...@gmail.com> wrote:
> On Fri, Aug 3, 2012 at 12:27 AM, Olemis Lang <ol...@gmail.com> wrote:
>> my comments below . Please recall that I'm not an expert neither in
>> the art of licensing nor in ASF best practices and standards .
>
> No worries. You've got myself as the first stop, and then the rest of
> Foundation as the second stop :-)
>
:)
>> On 8/2/12, Greg Stein <gs...@gmail.com> wrote:
>>...
>>> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>>> dir is proper. (and maybe generally simplify; eg. why CHANGES in
>>> bloodhound_dashboard?)
>>
>> Even if Bloodhound is distributed in a single file (tarball) it is
>> developed in the form of a set of plugins . bloodhound_* folders
>> contain source code for each one of them . License files are in there
>> because it makes sense to checkout only that particular subset of the
>> code in svn repos , build the corresponding plugin, install it and use
>> it . Indeed it's also possible to build packages for each plugin and
>> distribute them .
>>
>> Is this a reason good enough to keep license files in bloodhound_* folders
>> ?
>
> Nope.
>
> The LICENSE/NOTICE files are for releases, not for checkouts from our
> repository. By your logic, there would be a LICENSE/NOTICE in *every*
> subdirectory because people could check out anything.
>
I understand your point , but according to my reasoning that's not the
case but ...
> It is important to make a distinction here. If somebody checks out
> files from our repository, that is NOT a release. The ASF is not
> standing behind it as a release. The important work of the Foundation
> is when we make a release. And the *only* release that this project
> will make is the entire bundle (unless I'm horribly mistaken on the
> community goals here). Since the plugins will not be released
> individually, they exist merely as an architectural convenience. The
> *release* is trunk/ and that is where the LICENSE/NOTICE files should
> reside, and then be delivered in the resulting tarball to the users.
>
... after reading this I see there's no point in following the
discussion . It's clear to me now .
Thanks
>>...
>>> * would also be nice to indicate what release/revision of Trac is
>>> incorporated into this release,
>>
>> for Release 2 (... or maybe later) we have to work on this direction.
>> We need to know that information in code as well . Right now it turns
>> out that the revision number in the footer represents changeset ID
>> corresponding to ASF repos rather than Trac's . My initial suggestion
>> is to update footer with something like
>>...
>
> Sounds good!
>
;)
>>...
>> My second suggestion is to include in trunk a file named TRAC_VERSION
>> containing the version, changeset ID, ... of Trac code committed in
>> vendor branch .
>
> This would be great. Details TBD, and I don't really have any input
> for the dev community.
>
ok . that's to be continued in a separate thread
>> NOTICE , LICENSE and other files will only need to
>> mention that file (<= I'm hoping we can do that).
>
> There is no need for these files to refer to a proposed TRAC_VERSION
> file. It is sufficient to state "portions developed by..." (as they do
> now).
>
I said so in order to say something like this in e.g. NOTICE file .
"A modified copy of Trac is included in this source release package.
Exact version of Trac may be found in TRAC_VERSION file" ... etc , etc
..
>>...
>>> along with a notice that local patches
>>> have been applied.
>>
>> +1 ... and if current modifications need to be mentioned then maybe a
>> link to (or a copy of) aforementioned (non-existent) wiki page (i.e.
>> http://issues.apache.org/bloodhound/wiki/Patches) may be included as
>> well
>
> Trac's BSD license does NOT require any mention of changes. We do it
> because we're nice :-) ... not to mention that users may need/want to
> know that information (like I wondered when reviewing the tarball).
>
Exactly !
[...]
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Aug 3, 2012 at 12:27 AM, Olemis Lang <ol...@gmail.com> wrote:
> my comments below . Please recall that I'm not an expert neither in
> the art of licensing nor in ASF best practices and standards .
No worries. You've got myself as the first stop, and then the rest of
Foundation as the second stop :-)
> On 8/2/12, Greg Stein <gs...@gmail.com> wrote:
>...
>> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>> dir is proper. (and maybe generally simplify; eg. why CHANGES in
>> bloodhound_dashboard?)
>
> Even if Bloodhound is distributed in a single file (tarball) it is
> developed in the form of a set of plugins . bloodhound_* folders
> contain source code for each one of them . License files are in there
> because it makes sense to checkout only that particular subset of the
> code in svn repos , build the corresponding plugin, install it and use
> it . Indeed it's also possible to build packages for each plugin and
> distribute them .
>
> Is this a reason good enough to keep license files in bloodhound_* folders ?
Nope.
The LICENSE/NOTICE files are for releases, not for checkouts from our
repository. By your logic, there would be a LICENSE/NOTICE in *every*
subdirectory because people could check out anything.
It is important to make a distinction here. If somebody checks out
files from our repository, that is NOT a release. The ASF is not
standing behind it as a release. The important work of the Foundation
is when we make a release. And the *only* release that this project
will make is the entire bundle (unless I'm horribly mistaken on the
community goals here). Since the plugins will not be released
individually, they exist merely as an architectural convenience. The
*release* is trunk/ and that is where the LICENSE/NOTICE files should
reside, and then be delivered in the resulting tarball to the users.
>...
>> * would also be nice to indicate what release/revision of Trac is
>> incorporated into this release,
>
> for Release 2 (... or maybe later) we have to work on this direction.
> We need to know that information in code as well . Right now it turns
> out that the revision number in the footer represents changeset ID
> corresponding to ASF repos rather than Trac's . My initial suggestion
> is to update footer with something like
>...
Sounds good!
>...
> My second suggestion is to include in trunk a file named TRAC_VERSION
> containing the version, changeset ID, ... of Trac code committed in
> vendor branch .
This would be great. Details TBD, and I don't really have any input
for the dev community.
> NOTICE , LICENSE and other files will only need to
> mention that file (<= I'm hoping we can do that).
There is no need for these files to refer to a proposed TRAC_VERSION
file. It is sufficient to state "portions developed by..." (as they do
now).
>...
>> along with a notice that local patches
>> have been applied.
>
> +1 ... and if current modifications need to be mentioned then maybe a
> link to (or a copy of) aforementioned (non-existent) wiki page (i.e.
> http://issues.apache.org/bloodhound/wiki/Patches) may be included as
> well
Trac's BSD license does NOT require any mention of changes. We do it
because we're nice :-) ... not to mention that users may need/want to
know that information (like I wondered when reviewing the tarball).
>> (on that note: has anybody worked to push the local
>> changes upstream?)
>
> this is homework for trac-dev ML , I guess .
> Nonetheless I wanted to know something in advance . If trac-dev
> decides not to incorporate Bloodhound patches :
>
> 1. may we keep them in trunk ?
Yes. There is precedent within the Foundation, which is why I told
Ethan this is not a problem.
We *do* want to avoid forking Trac, so we'll just do what work is
possible to get necessary changes ported upstream.
> 2. should we refresh and apply every time Trac source
> code is updated in vendor branch ?
I believe you have a misunderstanding of vendor branches. The vendor
branch tracks upstream. Each time we pull from upstream, the vendor
branch(es) area is updated with those changes. Thus,
incubator/bloodhound/vendor/trac/* precisely mirrors the upstream.
Next, we have a copy of that in trunk/trac/. Local changes have been
made to that directory.
When the vendor branch area is updated to a newer revision from
upstream, those changes are then *merged* into trunk/trac/. Thus,
trunk/trac/ is always some copy of upstream + local changes.
(the individual steps are slightly different semantically, but suffice
it to say that the end result is that we get new copies of upstream
and we reapply the changes)
> 3. is there an easy (recommended ?) procedure to
> do (2) using subversion ?
Please read up on "vendor branches" in the svnbook:
http://svnbook.red-bean.com/en/1.1/ch07s05.html
Short is: we're already doing Best Practices for maintaining local
patches, with a goal of producing them for pushing upstream. (and
maintaining them locally as upstream continues development)
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
my comments below . Please recall that I'm not an expert neither in
the art of licensing nor in ASF best practices and standards .
On 8/2/12, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com>
> wrote:
>>...
>> Please vote:
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>
> +1 to release.
>
> Changes that I'd suggest for the next release:
>
[...]
>
> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
> dir is proper. (and maybe generally simplify; eg. why CHANGES in
> bloodhound_dashboard?)
Even if Bloodhound is distributed in a single file (tarball) it is
developed in the form of a set of plugins . bloodhound_* folders
contain source code for each one of them . License files are in there
because it makes sense to checkout only that particular subset of the
code in svn repos , build the corresponding plugin, install it and use
it . Indeed it's also possible to build packages for each plugin and
distribute them .
Is this a reason good enough to keep license files in bloodhound_* folders ?
> * found another NOTICE in doc/html-templates/ (?!)
+1 for removing it .
> * is doc/wireframes supposed to be shipped in the release?
I don't think so
[...]
> * would also be nice to indicate what release/revision of Trac is
> incorporated into this release,
for Release 2 (... or maybe later) we have to work on this direction.
We need to know that information in code as well . Right now it turns
out that the revision number in the footer represents changeset ID
corresponding to ASF repos rather than Trac's . My initial suggestion
is to update footer with something like
{{{
Powered by <a
href="http://www.apache.org/">Apache<sup>TM</sup></a> <a
href="http://issues.apache.org/bloodhound">Bloodhound</a>.
Standing on the shoulders of
<a href="http://trac.edgewall.org/">Trac ${correct_trac_version}</a>
(<a href="http://issues.apache.org/bloodhound/wiki/Patches">modified</a>)
}}}
... notice that we can use another URL instead of
http://issues.apache.org/bloodhound
My second suggestion is to include in trunk a file named TRAC_VERSION
containing the version, changeset ID, ... of Trac code committed in
vendor branch . NOTICE , LICENSE and other files will only need to
mention that file (<= I'm hoping we can do that). File format is TBD
.. and TBH I really don't care much about it as long as it will be
readable for users interested to know after reading NOTICE , ... At
the same time it also has to be easy to parse in order to use that
value to provide correct Trac version in about page , footer , ...
i.e. everywhere Trac version will be displayed .
> along with a notice that local patches
> have been applied.
+1 ... and if current modifications need to be mentioned then maybe a
link to (or a copy of) aforementioned (non-existent) wiki page (i.e.
http://issues.apache.org/bloodhound/wiki/Patches) may be included as
well
> (on that note: has anybody worked to push the local
> changes upstream?)
>
this is homework for trac-dev ML , I guess .
Nonetheless I wanted to know something in advance . If trac-dev
decides not to incorporate Bloodhound patches :
1. may we keep them in trunk ?
2. should we refresh and apply every time Trac source
code is updated in vendor branch ?
3. is there an easy (recommended ?) procedure to
do (2) using subversion ?
PS: refresh and apply means the equivalent of executing the following
steps with Hg MQ
- hg pull <trac_repository> <vendor_branch>
- hg update tip
- hg qpush
- <modify source code by paying attention to rejected hunks>
- hg qrefresh
- hg cp <vendor branch with patches> <trunk/trac>
- hg qpop
... well something like that . I hope you get the idea ;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
I would suggest running with the current tarball. You've got something
for the IPMC to comment upon. If it doesn't pass muster, then fine:
you'll just end up rolling up a new tarball anyways. May as well be
optimistic, and get some feedback while you're at it.
When forwarding to the IPMC, you may want to note that I've found some
licensing/notice issues which are planned to be fixed in the next
release. That will at least let them know we've seen them and intend
to fix them. (and it may help to have my name in there as
reviewed/approved) Each of the people who approved it (in a binding
fashion) should be listed in that email.
Cheers,
-g
On Thu, Aug 2, 2012 at 6:55 PM, Gary Martin <ga...@wandisco.com> wrote:
> Thanks for that Greg. I will raise tickets and fix as much of that as I can in the morning.
>
> That leaves the question of whether I should create the new release with these changes or carry on with the current tarball. Any other opinions?
>
> Cheers,
> Gary
>
>
>
> Greg Stein <gs...@gmail.com> wrote:
>
>>On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com>
>>wrote:
>>>...
>>> Please vote:
>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>> [ ] +0 Don't care
>>> [ ] -1 Do not release this package (please explain)
>>
>>+1 to release.
>>
>>Changes that I'd suggest for the next release:
>>
>>* append dependencies' licenses to LICENSE (in addition to their
>>reference in NOTICE)
>>* remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>>dir is proper. (and maybe generally simplify; eg. why CHANGES in
>>bloodhound_dashboard?)
>>* found another NOTICE in doc/html-templates/ (?!)
>>* is doc/wireframes supposed to be shipped in the release?
>>* found another LICENSE/NOTICE pair in installer/
>>* files like bloodhound_dashboard/setup.cfg (and other .ini format
>>files like ticket_data.ini) could use a license header (use of RAT
>>will find more of these)
>> - same with bloodhound_dashboard/macros.py
>> - run RAT before 0.2 release
>>* in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
>>then comment holding the license header comes before the DOCTYPE
>>element. not sure that is (formally) allowed. probably should have the
>>DOCTYPE, then the comment, then the <div>
>>* might be nice to have a top-level README that points to
>>installer/README.rst
>>* would also be nice to indicate what release/revision of Trac is
>>incorporated into this release, along with a notice that local patches
>>have been applied. (on that note: has anybody worked to push the local
>>changes upstream?)
>>
>>
>>That's all for now. While I think this it is fine to release in this
>>shape, I might also suggest incorporating the above changes and
>>produce a 0.1 tarball (no RC1 designator) and shoot that out for
>>another BH release vote followed by IPMC vote. (the IPMC vote will be
>>easier if RAT is run first, but I can beat down any hubbub even on
>>this RC1 if you go that route).
>>
>>On version numbers in general, they are cheap. There is no reason to
>>have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
>>release it, then make the next one 0.2 or 0.1.1. Never re-use a
>>number! ... but there isn't a reason to be so conservative as to make
>>a 0.1.0-RC1 tarball. In the long run, you probably want a standard
>>triple, so going with 0.1.0 makes sense. If people nuke that proposed
>>tarball, then spin up a new one called 0.1.1. As I've mentioned
>>before, once 0.1.x is out there, you probably wouldn't patch it at
>>this point of BH's lifecycle, and just go straight to 0.2.0 instead.
>>(tho I guess if it is a total brown-bag release, you could also do a
>>teeny patch and push out 0.1.x+1).
>>
>>Anyways. Food for thought. Again, I'm +1 on this tarball for release.
>>
>>Cheers,
>>-g
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Thanks for that Greg. I will raise tickets and fix as much of that as I can in the morning.
That leaves the question of whether I should create the new release with these changes or carry on with the current tarball. Any other opinions?
Cheers,
Gary
Greg Stein <gs...@gmail.com> wrote:
>On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com>
>wrote:
>>...
>> Please vote:
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>
>+1 to release.
>
>Changes that I'd suggest for the next release:
>
>* append dependencies' licenses to LICENSE (in addition to their
>reference in NOTICE)
>* remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>dir is proper. (and maybe generally simplify; eg. why CHANGES in
>bloodhound_dashboard?)
>* found another NOTICE in doc/html-templates/ (?!)
>* is doc/wireframes supposed to be shipped in the release?
>* found another LICENSE/NOTICE pair in installer/
>* files like bloodhound_dashboard/setup.cfg (and other .ini format
>files like ticket_data.ini) could use a license header (use of RAT
>will find more of these)
> - same with bloodhound_dashboard/macros.py
> - run RAT before 0.2 release
>* in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
>then comment holding the license header comes before the DOCTYPE
>element. not sure that is (formally) allowed. probably should have the
>DOCTYPE, then the comment, then the <div>
>* might be nice to have a top-level README that points to
>installer/README.rst
>* would also be nice to indicate what release/revision of Trac is
>incorporated into this release, along with a notice that local patches
>have been applied. (on that note: has anybody worked to push the local
>changes upstream?)
>
>
>That's all for now. While I think this it is fine to release in this
>shape, I might also suggest incorporating the above changes and
>produce a 0.1 tarball (no RC1 designator) and shoot that out for
>another BH release vote followed by IPMC vote. (the IPMC vote will be
>easier if RAT is run first, but I can beat down any hubbub even on
>this RC1 if you go that route).
>
>On version numbers in general, they are cheap. There is no reason to
>have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
>release it, then make the next one 0.2 or 0.1.1. Never re-use a
>number! ... but there isn't a reason to be so conservative as to make
>a 0.1.0-RC1 tarball. In the long run, you probably want a standard
>triple, so going with 0.1.0 makes sense. If people nuke that proposed
>tarball, then spin up a new one called 0.1.1. As I've mentioned
>before, once 0.1.x is out there, you probably wouldn't patch it at
>this point of BH's lifecycle, and just go straight to 0.2.0 instead.
>(tho I guess if it is a total brown-bag release, you could also do a
>teeny patch and push out 0.1.x+1).
>
>Anyways. Food for thought. Again, I'm +1 on this tarball for release.
>
>Cheers,
>-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Given Greg's response I hardly need to cover anything now so I will
leave my additional contributions to a few, hopefully short comments.
On 08/02/2012 11:42 PM, Ethan Jucovy wrote:
> Specifically, Bloodhound already depends on a patched copy of Trac which
> lives in the Bloodhound SVN repository under
> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and is
> distributed with the release. This raises a number of questions:
>
> * Some of the files in Bloodhound's modified copy of Trac core contain
> "Licensed to the Apache Software Foundation" headers.
> (trac/utils/tests/introspection.py and trac/util/introspection.py are the
> ones I've noticed, but I didn't grep the repository.) I think this is
> contrary to previous claims that Bloodhound's developers would keep all
> Trac modifications BSD-licensed, and that the individual authors would
> retain their copyright over these lines of code, for the sake of keeping
> Trac's BSD license intact for all upstream patches[1]. These license
> headers should be removed before a release.
Whilst it was not my intention to leave the file mentioned with that
license header, Greg's assertions that this is actually correct are good
enough for me for the moment. IF changes of this sort are accepted into
Trac then I would expect the license headers of such files in the
Bloodhound repository to reflect what they are in the Trac repositories.
Meanwhile, I am certainly going to consider the suggestion from Olemis
that the file is moved elsewhere, but this will not be considered a
change required for release.
> * Based on the earlier discussions on the Apache Incubator list, I'm not
> sure whether cutting a release that depends on a Trac distribution
> maintained by Bloodhound developers in the Apache Incubator's SVN satisfies
> ASF's guidelines and policies. [...]
From what I could tell, the vendor branch solution is entirely
acceptable and keeps a clear record of the differences directly in the
repositories. I think it is quite a neat, clear and convenient solution
for Bloodhound.
> * During the project's initiation the idea of maintaining short-term Trac
> patches in a branch-heavy Git repository or Mercurial patch queue was
> discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
> Why did Bloodhound's developers not take this approach after saying they
> would?
I do come back to this myself every now and then. It is not so much a
final decision as what is necessary for us to get our work done on a
continuing basis.
> * What tag/revision of Trac core is the code diverging from? Where is
> this documented? How often do Bloodhound's developers merge in upstream
> changes, and what is their policy for deciding when to merge upstream
> changes?
How we do the job of merging changes from Trac is really more our
problem but the general principles are specified here:
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html
As for policy on when to merge, there is no policy and I do not wish to
enforce one at this point. As a general principle I would like the
vendor code to be considered for updating once a release but we should
not need to commit to anything at this point. It would be normal to
discuss the need for such changes on this list.
> * It looks like Bloodhound currently depends on three upstream Trac
> plugins -- where are Bloodhound's issues filed against those plugins being
> tracked?
I also do not know how this is particularly relevant. However, at the
moment we would probably expect to track the issue locally as well as
notify in the plugin's issue tracker. There are already examples of this
happening and so far interactions of this form have been largely
positive when there is a response.
Cheers,
Gary
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 2, 2012 at 6:42 PM, Ethan Jucovy <et...@gmail.com> wrote:
> -1
When you posted this, you may have already been aware of Apache voting
procedures, but please let me clarify in case others in the community
are not aware:
1) Your vote doesn't count. It is considered "non-binding", meaning it
does not "bind to the issue at hand". Thus, it is
advisory/discretionary/commentative/etc. Only people on the (P)PMC
have binding votes. And hopefully, they listen to non-binding votes as
important and useful input.
2) Releases cannot be vetoed. A release requires three (binding) +1
votes, and it is good to go. In short, there is no way to stop
productivity at the ASF. (vetoes on commits only sort of stop it...
the goal is to actually find a new/better solution rather than halt
the idea)
The RC1 tarball that Gary has prepared has received enough +1 votes to
be forwarded onto the Incubator PMC for release voting/consideration.
> (Note: I've been travelling recently without much internet access, and will
> continue to be for the next few weeks.)
You have a tendency to show up AFTER events have already occurred. If
you want to participate, then DO SO. Showing up after the fact and
saying "STOP. You must halt what you're doing" will not win you any
friends or respect.
> I haven't seen any significant movement on the Trac<->Bloodhound community
> issues discussed during Bloodhound's initial project proposal. The
So? That has no bearing on this release. It is something to work on, sure.
> Bloodhound developers also seem to have backtracked on the specific
> resolutions made during the initial discussions, and haven't yet
> established any workflows or documentation to ensure good communication
> with the Trac community. If these issues are not addressed before the
This is a volunteer community. We do not have "workflows" or
"procedures" or other monkey stuff. We try and get stuff done. That is
happening.
Is there more work to talk to the Trac community? Sure. But speaking
for myself, I find trying to get a release done is of higher
importance. It helps to establish traction and direction, which can
then help construct/attract a community. Building a community is first
priority, and *that* community can then begin to engage with the Trac
people.
(and, btw, there were no "resolutions made" at any time; only the
Board passes resolutions)
> initial release, Bloodhound's current working code and development
> workflows will gain inertia, and increase the risk of a permanent de facto
> fork.
As Gary said, that is nobody's intention.
> Specifically, Bloodhound already depends on a patched copy of Trac which
> lives in the Bloodhound SVN repository under
> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and is
> distributed with the release. This raises a number of questions:
>
> * Some of the files in Bloodhound's modified copy of Trac core contain
> "Licensed to the Apache Software Foundation" headers.
> (trac/utils/tests/introspection.py and trac/util/introspection.py are the
> ones I've noticed, but I didn't grep the repository.) I think this is
> contrary to previous claims that Bloodhound's developers would keep all
> Trac modifications BSD-licensed, and that the individual authors would
> retain their copyright over these lines of code, for the sake of keeping
> Trac's BSD license intact for all upstream patches[1].
The license headers for NEW files probably *should* have an ASF
license header on them (as an effect of the committers' ICLA). If/when
the Trac people want to accept the patches which incorporate those
files, then the various authors can agree to the BSD license *IF* the
Trac devs want that to happen. It is entirely possible that Trac will
be just fine with the ALv2 header on there (it *is* compatible with
BSD, after all).
But that is for another time, when those files get moved upstream. And
it is also based on what the Trac devs want, rather than your personal
thoughts.
> These license
> headers should be removed before a release.
There is no "should" about it. They can remain in a release from the
ASF. That is perfectly fine. They *may* be removed in a future
release, but that is for another time, another discussion.
> * Based on the earlier discussions on the Apache Incubator list, I'm not
> sure whether cutting a release that depends on a Trac distribution
> maintained by Bloodhound developers in the Apache Incubator's SVN satisfies
> ASF's guidelines and policies.
It does satisfy ASF guidelines/policy. End of story.
> The patched Trac distribution should
> probably be moved to a public code-hosting site like Sourceforge, Github or
> Bitbucket, instead of continuing to live in the ASF SVN. The release
> should then point to a tag at that new location for installation, instead
> of distributing the patched Trac code with the release itself.
No. It is easier for the Bloodhound developers to work with it right
where it is, which is why this approach was selected.
> * During the project's initiation the idea of maintaining short-term Trac
> patches in a branch-heavy Git repository or Mercurial patch queue was
> discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
> Why did Bloodhound's developers not take this approach after saying they
> would?
As above: ease for the developers. Whether they said they would do it,
or just consider it, or whatever... the final decision was that
maintaining a vendor branch in svn would be easiest all around.
> * What tag/revision of Trac core is the code diverging from? Where is
> this documented?
$ BH=http://svn.apache.org/repos/asf/incubator/bloodhound
$ svn log $BH/vendor/trac
As you can see, it is based off of Trac's trunk rev 11046.
> How often do Bloodhound's developers merge in upstream
> changes,
As you can see, the vendor branch was constructed in March and updated in May.
> and what is their policy for deciding when to merge upstream
> changes?
Whenever a developer feels like it. No policy so far.
> * The patched copy of Trac seems to have a few-hundred-line diff from the
> official Trac distribution. (I'm not sure the best way to measure this.)
$ svn diff $BH/vendor/trac/0.13dev_r11046 $BH/trunk/trac
About 400 lines of diff output.
Vendor branches are used specifically to track local modifications.
The process that BH is using is proper/appropriate for tracking local
mods in order to get them moved upstream.
> Where are these patches (and their intentions, and the Bloodhound code
> that relies on each patch) being tracked and documented as core patches?
> What procedures are in place to ensure that each core patch is being
> tracked and documented?
See above comment about "procedures".
> * Have all of these patches been submitted upstream to the Trac core
> community?
No.
> Where are the upstream submissions being tracked and
> documented? (I tried several searches on trac.edgewall.org and couldn't
> find any such tickets.) What procedures are in place to ensure that each
> core patch is filed upstream, and to track the upstream status of each core
> patch?
See above comment about "procedures".
> * If the Trac core developers reject a patch or suggest an alternate
> approach, will Bloodhound's developers take that advice and rework their
> own code? What procedures are being developed to ensure that this will
> happen, rather than the expedient route of continuing to rely on a patched
> Trac copy?
See above comment about "procedures".
If a patch is rejected, then we'll cross that bridge when it happens.
Until we know the parameters of the rejection, and the specific
example, then it is impossible to answer what is the best approach.
> * It looks like Bloodhound currently depends on three upstream Trac
> plugins -- where are Bloodhound's issues filed against those plugins being
> tracked?
Have any been filed? What is the concern here? Who said they would not
be filed with the author(s) of those plugins?
I don't see the relevance of this point.
> I'm aware of only one instance where an upstream patch was discussed with
> the Trac community so far[5]. In that instance, a Trac developer said the
> relevant plugin code was in error and suggested an alternate approach[6]
> that would patch the faulty plugin code instead of working around it with a
> core patch. This was filed but has not yet been acted on[7], and
> Bloodhound's developers did not all seem to agree that the advice from
> upstream should be followed[8, 9]; instead of patching the plugin code or
> fixing it upstream, the Bloodhound release continues to use the rejected
> core Trac patch.
So? Let me repeat: this is a volunteer community. Maybe nobody has
picked up and tried to solve that issue yet. Each developer has their
own set of priorities. If you have different priorities, then you can
work on the issue yourself. You certainly can't demand that others
work according to *your* priorities.
Again: IMO, a release is of critical importance, even there are lots
of problems with it, so I feel the community is proceeding properly.
>... snip ...
> To be clear, I don't think Bloodhound's initial releas requires a
> completely smooth procedure and infrastructure for tracking patches,
> submitting upstream contributions, and reworking changes based on upstream
> feedback.
Good. I don't think it needs any of those things.
In another year? it probably should.
> (Though the specific "technical" questions about licensing and
> code location should be addressed now.)
There is that "should" again. My response is "no, they don't".
Incubator releases are allowed to have licensing quirks as long as
there is a PLAN to get them fixed. And they MUST be fixed before
graduation. But there is no "should" at this stage of incubation.
> But those questions should be considered part of the release process.
I think you have a misunderstanding of the Apache release process, so
please do not attempt to dictate the operation of this project.
> Partly because it's the best/only formal opportunity in the development
> cycle to make sure the upstream/downstream workflow is running smoothly.
> And also because, after a release is made, inertia will build for just
> leaving patches in place as-is instead of waiting for upstream feedback and
> potentially rewriting features that are already working in the wild.
Thank you for the opinion. If others have time and inclination to make
this a personal priority, then it will happen.
> So I
> think it would be more prudent to postpone the initial release until
> working first drafts of these knowledge-maintenance/collaboration workflows
> have been established among Bloodhound's developers.
That is your opinion, and as mentioned at the top of this email: it
will not stop the release.
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
Hi Ethan,
I will consider your response in greater detail in the morning.
I will check up on the file you found in the trac directories. This would indeed be a mistake.
In a very general point on the rest of your concerns, there remains no intention to fork as it would not be in the best interest of any of the communities involved, and we will be discussing the changes that we find to be requirements of our solution with trac in the hope that these would enhance trac as well.
Anyway, I will talk more about this in the morning. Thanks for the input.
Cheers,
Gary
Ethan Jucovy <et...@gmail.com> wrote:
>-1
>
>(Note: I've been travelling recently without much internet access, and
>will
>continue to be for the next few weeks.)
>
>I haven't seen any significant movement on the Trac<->Bloodhound
>community
>issues discussed during Bloodhound's initial project proposal. The
>Bloodhound developers also seem to have backtracked on the specific
>resolutions made during the initial discussions, and haven't yet
>established any workflows or documentation to ensure good communication
>with the Trac community. If these issues are not addressed before the
>initial release, Bloodhound's current working code and development
>workflows will gain inertia, and increase the risk of a permanent de
>facto
>fork.
>
>Specifically, Bloodhound already depends on a patched copy of Trac
>which
>lives in the Bloodhound SVN repository under
>https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and
>is
>distributed with the release. This raises a number of questions:
>
> * Some of the files in Bloodhound's modified copy of Trac core contain
>"Licensed to the Apache Software Foundation" headers.
>(trac/utils/tests/introspection.py and trac/util/introspection.py are
>the
>ones I've noticed, but I didn't grep the repository.) I think this is
>contrary to previous claims that Bloodhound's developers would keep all
>Trac modifications BSD-licensed, and that the individual authors would
>retain their copyright over these lines of code, for the sake of
>keeping
>Trac's BSD license intact for all upstream patches[1]. These license
>headers should be removed before a release.
>
>* Based on the earlier discussions on the Apache Incubator list, I'm
>not
>sure whether cutting a release that depends on a Trac distribution
>maintained by Bloodhound developers in the Apache Incubator's SVN
>satisfies
>ASF's guidelines and policies. The patched Trac distribution should
>probably be moved to a public code-hosting site like Sourceforge,
>Github or
>Bitbucket, instead of continuing to live in the ASF SVN. The release
>should then point to a tag at that new location for installation,
>instead
>of distributing the patched Trac code with the release itself.
>
>* During the project's initiation the idea of maintaining short-term
>Trac
>patches in a branch-heavy Git repository or Mercurial patch queue was
>discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
>Why did Bloodhound's developers not take this approach after saying
>they
>would?
>
> * What tag/revision of Trac core is the code diverging from? Where is
>this documented? How often do Bloodhound's developers merge in
>upstream
>changes, and what is their policy for deciding when to merge upstream
>changes?
>
>* The patched copy of Trac seems to have a few-hundred-line diff from
>the
>official Trac distribution. (I'm not sure the best way to measure
>this.)
> Where are these patches (and their intentions, and the Bloodhound code
>that relies on each patch) being tracked and documented as core
>patches?
> What procedures are in place to ensure that each core patch is being
>tracked and documented?
>
> * Have all of these patches been submitted upstream to the Trac core
>community? Where are the upstream submissions being tracked and
>documented? (I tried several searches on trac.edgewall.org and
>couldn't
>find any such tickets.) What procedures are in place to ensure that
>each
>core patch is filed upstream, and to track the upstream status of each
>core
>patch?
>
> * If the Trac core developers reject a patch or suggest an alternate
>approach, will Bloodhound's developers take that advice and rework
>their
>own code? What procedures are being developed to ensure that this will
>happen, rather than the expedient route of continuing to rely on a
>patched
>Trac copy?
>
> * It looks like Bloodhound currently depends on three upstream Trac
>plugins -- where are Bloodhound's issues filed against those plugins
>being
>tracked?
>
>I'm aware of only one instance where an upstream patch was discussed
>with
>the Trac community so far[5]. In that instance, a Trac developer said
>the
>relevant plugin code was in error and suggested an alternate
>approach[6]
>that would patch the faulty plugin code instead of working around it
>with a
>core patch. This was filed but has not yet been acted on[7], and
>Bloodhound's developers did not all seem to agree that the advice from
>upstream should be followed[8, 9]; instead of patching the plugin code
>or
>fixing it upstream, the Bloodhound release continues to use the
>rejected
>core Trac patch.
>
>The plugin in question is well known and hasn't been maintained by its
>original author for more than two years (hence its incompatibility with
>Trac trunk) so this is a good example of why these questions matter.
>If
>Bloodhound's development workflows prioritized following advice from
>Trac
>core and submitted a good patch against ThemeEngine (maintaining a
>vendor
>branch // patch queue // short-lived fork of the plugin code in the
>meantime) then one of Bloodhound's developers could probably adopt
>maintenance for the plugin through existing Trac community channels
>pretty
>easily, which would benefit the wider Trac community.
>
>To be clear, I don't think Bloodhound's initial releas requires a
>completely smooth procedure and infrastructure for tracking patches,
>submitting upstream contributions, and reworking changes based on
>upstream
>feedback. (Though the specific "technical" questions about licensing
>and
>code location should be addressed now.)
>
>But those questions should be considered part of the release process.
>Partly because it's the best/only formal opportunity in the development
>cycle to make sure the upstream/downstream workflow is running
>smoothly.
> And also because, after a release is made, inertia will build for just
>leaving patches in place as-is instead of waiting for upstream feedback
>and
>potentially rewriting features that are already working in the wild.
>So I
>think it would be more prudent to postpone the initial release until
>working first drafts of these knowledge-maintenance/collaboration
>workflows
>have been established among Bloodhound's developers.
>
>-Ethan
>
>[1]
>http://www.mail-archive.com/bloodhound-dev@incubator.apache.org/msg00003.html
>[2]
>http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201201.mbox/%3C4F07380E.7060505@wandisco.com%3E
>[3] http://osdir.com/ml/trac-dev/2012-01/msg00023.html
>[4]
>http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3C96BC3F76-A04A-4382-9CC1-547CA6757F9C@dslextreme.com%3E
>[5]
>http://old.nabble.com/Create-new-ticket-vs-reopen--9418-(if-necessary--)-td33164546.html
>[6]
>http://old.nabble.com/Re%3A-Create-new-ticket-vs-reopen--9418-%28if-necessary--%29-p33176708.html
>[7] https://issues.apache.org/bloodhound/ticket/27
>[8]
>http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201204.mbox/%3CCAGMZAuPywg_QLUfiL4MEAR-57at22V8Oe=Yhr1+Hy3m8sxOexQ@mail.gmail.com%3E
>[9] http://trac-hacks.org/ticket/9580#comment:3
>
>On Thu, Aug 2, 2012 at 2:14 PM, Greg Stein <gs...@gmail.com> wrote:
>
>> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin
><ga...@wandisco.com>
>> wrote:
>> >...
>> > Please vote:
>> > [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> > [ ] +0 Don't care
>> > [ ] -1 Do not release this package (please explain)
>>
>> +1 to release.
>>
>> Changes that I'd suggest for the next release:
>>
>> * append dependencies' licenses to LICENSE (in addition to their
>> reference in NOTICE)
>> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>> dir is proper. (and maybe generally simplify; eg. why CHANGES in
>> bloodhound_dashboard?)
>> * found another NOTICE in doc/html-templates/ (?!)
>> * is doc/wireframes supposed to be shipped in the release?
>> * found another LICENSE/NOTICE pair in installer/
>> * files like bloodhound_dashboard/setup.cfg (and other .ini format
>> files like ticket_data.ini) could use a license header (use of RAT
>> will find more of these)
>> - same with bloodhound_dashboard/macros.py
>> - run RAT before 0.2 release
>> * in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
>> then comment holding the license header comes before the DOCTYPE
>> element. not sure that is (formally) allowed. probably should have
>the
>> DOCTYPE, then the comment, then the <div>
>> * might be nice to have a top-level README that points to
>> installer/README.rst
>> * would also be nice to indicate what release/revision of Trac is
>> incorporated into this release, along with a notice that local
>patches
>> have been applied. (on that note: has anybody worked to push the
>local
>> changes upstream?)
>>
>>
>> That's all for now. While I think this it is fine to release in this
>> shape, I might also suggest incorporating the above changes and
>> produce a 0.1 tarball (no RC1 designator) and shoot that out for
>> another BH release
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 13, 2012 9:06 PM, "Olemis Lang" <ol...@gmail.com> wrote:
>
> Hi !
>
> On 8/13/12, Ethan Jucovy <et...@gmail.com> wrote:
>....
> > But also note that excanvas.js is distributed under the Apache license;
it
> > doesn't say "Licened to the Apache Software Foundation" (AFAIK) - see
> > below.
Certainly. The statements mean entirely different things, and each is
correct. Not a problem.
>...
> > I was not very clear in my original message though. The "Licensed to
the
> > Apache Software Foundation under one or more contributor license
> > agreements" header is not itself an Apache license.
It isn't meant to be. It is telling you the status of the file, and where
to find the license.
So. What is your point?
>...
> > I'm not sure what it
> > actually means
Then why are you presupposing a problem exists? Why are you sending this
email?
If you wish to learn, then go do some reading rather than distracting the
community. Ask on license-discuss@apache.org for pointers. SOMETHING
besides uninformed hypotheses.
> > but I my understanding is that it indicates, as well as an
> > Apache license, a copyright assignment to ASF (presumably necessary
because
> > it is original code in ASF's subversion repository)
I wish you would actually learn about the ASF's licensing practices, rather
than waste Olemis' and my time.
No copyright assignment to the ASF has ever occurred. We don't accept them.
>...
> > which would have to(?)
> > be revoked in case of upstream contribution.
No. I told you this is my initial reply.
>...
> > This, again, seems like a lot
> > of artificial barriers to integration.
No. No such barrier exists.
Learn and ask, before making such stipulations.
>...
> > But other messages in this thread
> > seem to say that this will not be a problem and/or will be moot in the
case
> > of these specific files.
Exactly. So what is your problem? Move on to substantive issues.
>...
> > That said, this set of complications was one of the factors in the
original
> > decision(?) by Bloodhound's developers to work on Trac core
modifications
> > outside the ASF SVN (e.g. Github) and [therefore be able] to keep all
> > modifications BSD-licensed; hence my asking why the developers changed
> > their mind, and questioning whether the added convenience should really
> > outweigh the ensuing headaches.
It has been done. I agree with their choice. Where the core patches are
made is irrelevant. They *will* be made. May as well group them in the same
place.
>...
> Q - Is there any part licensed under ALv2 a candidate
> to be committed upstream ?
> A - *NO*
Well... maybe some of it may be offered/accepted, but should the upstream
devs ask for a license change (that is not a given!), then it can be one.
No problems, and no impediment.
>...
> > My "-1" referred to the licensing and code
> > location aspects, and to the fact that these questions had not yet been
> > raised and discussed, and no more.
The licensing aspects are fine, as I covered in my email. You need to learn
more about IP at the ASF before you question the approach. I did a review
of the tarball. I will perform more reviews in the future. If you have
information or belief that that is insufficient, then I welcome your
concerns.
> ... I don't see why that's necessary to release o.1.0-rc1 . I do see
> these subjects might be addressed before graduating the project from
> Incubation process
All licensing issues MUST be addressed before graduation. There is no
"might be".
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
Hi !
On 8/13/12, Ethan Jucovy <et...@gmail.com> wrote:
>
[...]
>
> As I've said before, I am not questioning whether the Bloodhound developers
> *intend* to fork Trac. My concern has always been whether a fork will be
> established as an unintended consequence.
>
Considering the work we have made so far I'd rather say that the main
goal has not been to fork Trac . We've basically done that in spite of
been able to customize our own copy as a last recourse needed by new
features without waiting for trac-dev to commit them upstream . I
think I'm accurate when I say that at present >95% of the code belongs
in the plugins ...
> Building a product on top of a system that's already more of an application
> than a framework and that has a large plugin ecosystem, without fracturing
> the community or breaking compatibility, is hard.
... hence Bloodhound , at least the way it stands today , will not
cause any harm to Trac community harder than any other plugin due to
the fact that it is basically *a set of plugins*
[...]
>
> On Fri, Aug 3, 2012 at 3:56 AM, Olemis Lang <ol...@gmail.com> wrote:
>>> * Some of the files in Bloodhound's modified copy of Trac core contain
>>> "Licensed to the Apache Software Foundation" headers.
>>> (trac/utils/tests/introspection.py and trac/util/introspection.py are
> the
>>> ones I've noticed, but I didn't grep the repository.)
>>
>> well I did , and this is what I found (a summary of course ;)
>
> Thanks, I appreciate that.
>
:)
>> 4. finally consider the fact that we have applied bigger
>> modifications on other files and did not change license
>> headers at all .
>
> Point taken. I guess I wonder then why newly created files should be
> licensed differently. (But I think I answered this question for myself
> below: "original code".)
>
Maybe. Just notice that we do not create new files deliberately . For
instance , if there's a new utility function for dates and times ,
then it should be included in `trac.util.datefmt` module . If function
processes text then it should be included in `trac.util.text` module ,
... and so on ...
>> 1. what's the reason for so much noise ?
>> 2. if we suggest a patch upstream containing a whole
>> new file we did from scratch . Why is it that you
>> complain about it whereas Google's source code
>> released under the terms of the same license
>> is accepted with pleasure ?
>
> Presumably in the excanvas.js case the file already existed with that
> license when Trac's developers chose to integrate it, so there was no real
> chance of it being otherwise.
>
> But also note that excanvas.js is distributed under the Apache license; it
> doesn't say "Licened to the Apache Software Foundation" (AFAIK) - see
> below.
>
Of course not . It says «Copyright 2006 Google Inc.» .
>> 3. in case we are the original authors (the project I mean)
>> like in (2) why can't we propose a file with AL v2 header ?
>
> This was discussed in a lot of detail in the original thread on trac-dev
> about Bloodhound; it's not that you *can't*, it just creates avoidable
> complications, either for the developers or for later consumers of the
> code, in case of integration.
>
yes , I recall
> I was not very clear in my original message though. The "Licensed to the
> Apache Software Foundation under one or more contributor license
> agreements" header is not itself an Apache license.
AFAIK , yes it is when combined with the rest , considering the fact
that the license makes space for that to happen . Nonetheless I'm not
an expert , so I won't follow beyond that comment .
> I'm not sure what it
> actually means but I my understanding is that it indicates, as well as an
> Apache license, a copyright assignment to ASF (presumably necessary because
> it is original code in ASF's subversion repository)
Compared to excanvas.py , in there you have an explicit copyright
statement and ...
> which would have to(?)
> be revoked in case of upstream contribution.
... afaics it was not revoked at all ... and you can upgrade (already
done ? guess so ...) excanvas.py at any time .
> This, again, seems like a lot
> of artificial barriers to integration.
so I repeat , what's the matter in this particular case.
> But other messages in this thread
> seem to say that this will not be a problem and/or will be moot in the case
> of these specific files.
>
*seem* => interpretation => may be not accurate => not actually
happened => why bother ?
> That said, this set of complications was one of the factors in the original
> decision(?) by Bloodhound's developers to work on Trac core modifications
> outside the ASF SVN (e.g. Github) and [therefore be able] to keep all
> modifications BSD-licensed; hence my asking why the developers changed
> their mind, and questioning whether the added convenience should really
> outweigh the ensuing headaches.
>
<joke>
it's a conspiracy . trust me .
</joke>
<serious>
Please focus on this now .
Q - Have we proposed any patch upstream ?
A - No
Q - Should we ?
A - yes
Q - Is there any part licensed under ALv2 a candidate
to be committed upstream ?
A - *NO*
So I ask , what's the reason for all that noise ?
nothing like this has actually happened , and nothing similar has been
discussed with trac-dev yet . Continuing with this is kind of a
science fiction movie for the time being . Who knows ... might be a
good subject later
</serious>
[...]
>
>> 1. user reports an issue in Bloodhound issue tracker
>> 2. we analyze it and determine if it's an error in third-party plugin
>> 3. we forward the issue to plugin's issue tracker and close
>> Bloodhound's as wontfix , providing all the details so that
>> it will be possible for users to follow the discussion in
>> forwarded ticket page .
>> 4. we are not responsible anymore
>>
>> ... at least that's the way (I think) it should work as long as we do
>> not include code for third-party plugins in ASF repository and take
>> responsibility for maintaining it .
>
> Well, this seems odd to me -- I would think that it would be easier, in
> both the short term and the long term, to use vendor branches of plugins as
> well as a vendor branch of Trac itself.
I think you misunderstood my answer , mainly by ignoring this phrase *
as long as we do not include code for third-party plugins in ASF
repository *
> Having different workflows for
> patching Trac core and patching plugins seems like an artificial barrier to
> implementing "the most correct" fixes.
There's no way I said that . The phrase above means «we can not take
responsibility for improving all plugins out there, hence we'll
forward issues to original plugin authors if we determine it's beyond
the scope of the project» . I didn't want to entangle with the case
when a patch for plugin is required , and I won't now either ...
> But I may be assuming a deeper
> dependency on select plugins than Bloodhound currently has; maybe this will
> happen as soon as plugin patches are needed.
>
... at least until we have an scenario like this
>> TBH plugin code was not in error , I mean there was no semantic nor
>> even a programming error . In few words the answer was «we changed
>> Trac code for a good reason and what everybody used to do before will
>> not work now . you have to over-complicate your code and stick to our
>> new policies (<= do not enumerate extension points in component's
>> initializer if it implements target interface)» . I honestly don't
>> agree with trac-dev decision so , in the end we decided that such a
>> situation (i.e. enumerating ExtensionPoint objects in initializers of
>> classes implementing target interface) will happen quite often in our
>> code and preferred not to over-complicate plugin code , use locks ,
>> etc, etc (oh my !) ...
>
> I think this indicates the gray area between patching core as a "last
> recourse" and patching core because you don't agree with core's approach.
> As you say, there are other ways to do this -- they're just
> "over-complicated," or require rethinking your solutions. I don't think
> it's very common for components to implement an interface that they also
> have as an extension point; does ThemeEngine really *need* to do this to
> function?
ThemePlugin does so in order to ensure that default theme will always
be available if theme engine is active as a single component needs to
be activated for both cases.
> Do your other instances?
fwiw we have some other cases , and this also happens .
> If so, does it really *need* to
> iterate over the extension point in its initializer and not in a lazily
> evaluated property?
>
the point here is ...
Q - Can we fix that without modifying ThemeEnginePlugin
source code?
A - No
Q - Can we take ownership ?
A - Not yet (... like I already said ...)
Q - Do we want to wait 2 more years for this problem
to be fixed ?
A - Hmmm ... no
Q - The semantics of enumerating an entry point descriptor
are they really so particular so as to allow for doing so
everywhere except in component's initializer under
very particular circumstances ?
A - Definitely not . People's been doing so since long time
ago and it worked . The fact is that some modifications
included in
Trac=0.12 break entry point semantics by raising a
completely odd infinite recursion error. Suddenly
the simple operation of listing components in a collection
becomes a matter of mutexes , locks , thread
synchronization, lazy access , properties ... you
can even add your favorite daemons to the list .
We decided to stick with common and not to break
plugins code .
[...]
>> Nonetheless there's a ticket opened somewhere
>> in ThemeEnginePlugin issue tracker. If we ever manage to find out a
>> generic , clean and simple solution not relying on a core patch , we
>> will try to revert our changes and use it once we test everything is
>> ok with it . The way I see it that has not happened yet .
>
> FWIW this is exactly the sort of thing that would benefit from a milestone,
> keyword or other piece of structured metadata, including the reference to
> the ThemeEngine ticket.
>
maybe
> My "-1" referred to the licensing and code
> location aspects, and to the fact that these questions had not yet been
> raised and discussed, and no more.
>
Oranges and apples . That's the way I see it *now* . Even if you might
be right regarding the fact that there's a lot more to do , etc , etc
... I don't see why that's necessary to release o.1.0-rc1 . I do see
these subjects might be addressed before graduating the project from
Incubation process . AFAIK that's not an immediate milestone right
now.
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Ethan Jucovy <et...@gmail.com>.
First, in general: since Greg at least clearly misunderstood the spirit of
my message, let me clarify a few things. My intention was certainly not to
block or dictate anything. *My vote* represents *my opinion* (it was made
with full knowledge that it carries no formal weight) and everything that I
said was a recommendation and no more.
As I've said before, I am not questioning whether the Bloodhound developers
*intend* to fork Trac. My concern has always been whether a fork will be
established as an unintended consequence.
Building a product on top of a system that's already more of an application
than a framework and that has a large plugin ecosystem, without fracturing
the community or breaking compatibility, is hard. In my experience it is
much, much harder if those goals aren't built in to the development
practices from the start, and if evaluating progress against those goals
isn't tied to the project's existing lifecycle. Among other reasons, this
is because maintaining upstream technical-and-community compatibility will
NEVER be anyone's first-order priority -- basically by definition, since
it's both more abstract and longer-term than any particular feature, bug
fix, milestone, etc.
Hence my questions: my point was not that comprehensive answers should be
provided before the first release, but that the questions should be raised
before the first -- and every subsequent -- release, because release-time
is the most (only) natural moment for evaluation.
I'll respond to a few specifics below.
On Fri, Aug 3, 2012 at 3:56 AM, Olemis Lang <ol...@gmail.com> wrote:
>> * Some of the files in Bloodhound's modified copy of Trac core contain
>> "Licensed to the Apache Software Foundation" headers.
>> (trac/utils/tests/introspection.py and trac/util/introspection.py are
the
>> ones I've noticed, but I didn't grep the repository.)
>
> well I did , and this is what I found (a summary of course ;)
Thanks, I appreciate that.
> 4. finally consider the fact that we have applied bigger
> modifications on other files and did not change license
> headers at all .
Point taken. I guess I wonder then why newly created files should be
licensed differently. (But I think I answered this question for myself
below: "original code".)
> 1. what's the reason for so much noise ?
> 2. if we suggest a patch upstream containing a whole
> new file we did from scratch . Why is it that you
> complain about it whereas Google's source code
> released under the terms of the same license
> is accepted with pleasure ?
Presumably in the excanvas.js case the file already existed with that
license when Trac's developers chose to integrate it, so there was no real
chance of it being otherwise.
But also note that excanvas.js is distributed under the Apache license; it
doesn't say "Licened to the Apache Software Foundation" (AFAIK) - see below.
> 3. in case we are the original authors (the project I mean)
> like in (2) why can't we propose a file with AL v2 header ?
This was discussed in a lot of detail in the original thread on trac-dev
about Bloodhound; it's not that you *can't*, it just creates avoidable
complications, either for the developers or for later consumers of the
code, in case of integration.
I was not very clear in my original message though. The "Licensed to the
Apache Software Foundation under one or more contributor license
agreements" header is not itself an Apache license. I'm not sure what it
actually means but I my understanding is that it indicates, as well as an
Apache license, a copyright assignment to ASF (presumably necessary because
it is original code in ASF's subversion repository) which would have to(?)
be revoked in case of upstream contribution. This, again, seems like a lot
of artificial barriers to integration. But other messages in this thread
seem to say that this will not be a problem and/or will be moot in the case
of these specific files.
That said, this set of complications was one of the factors in the original
decision(?) by Bloodhound's developers to work on Trac core modifications
outside the ASF SVN (e.g. Github) and [therefore be able] to keep all
modifications BSD-licensed; hence my asking why the developers changed
their mind, and questioning whether the added convenience should really
outweigh the ensuing headaches.
>> How often do Bloodhound's developers merge in upstream
>> changes, and what is their policy for deciding when to merge upstream
>> changes?
>
> … I think this deserves a whole new thread forked from here , if you
follow .
I agree, FWIW.
> The only thing I suggest is
> to create a ticket in a particular milestone (e.g. upstream_reject) to
> watch for this , because there's a chance that e.g. three years later
> Trac evolves and fortunately there will be a way to do the same thing
> using new or modified APIs .
I agree with this too -- it would be nice to find these kinds of issues
through structured ticket queries in some way.
> 1. user reports an issue in Bloodhound issue tracker
> 2. we analyze it and determine if it's an error in third-party plugin
> 3. we forward the issue to plugin's issue tracker and close
> Bloodhound's as wontfix , providing all the details so that
> it will be possible for users to follow the discussion in
> forwarded ticket page .
> 4. we are not responsible anymore
>
> ... at least that's the way (I think) it should work as long as we do
> not include code for third-party plugins in ASF repository and take
> responsibility for maintaining it .
Well, this seems odd to me -- I would think that it would be easier, in
both the short term and the long term, to use vendor branches of plugins as
well as a vendor branch of Trac itself. Having different workflows for
patching Trac core and patching plugins seems like an artificial barrier to
implementing "the most correct" fixes. But I may be assuming a deeper
dependency on select plugins than Bloodhound currently has; maybe this will
happen as soon as plugin patches are needed.
> TBH plugin code was not in error , I mean there was no semantic nor
> even a programming error . In few words the answer was «we changed
> Trac code for a good reason and what everybody used to do before will
> not work now . you have to over-complicate your code and stick to our
> new policies (<= do not enumerate extension points in component's
> initializer if it implements target interface)» . I honestly don't
> agree with trac-dev decision so , in the end we decided that such a
> situation (i.e. enumerating ExtensionPoint objects in initializers of
> classes implementing target interface) will happen quite often in our
> code and preferred not to over-complicate plugin code , use locks ,
> etc, etc (oh my !) ...
I think this indicates the gray area between patching core as a "last
recourse" and patching core because you don't agree with core's approach.
As you say, there are other ways to do this -- they're just
"over-complicated," or require rethinking your solutions. I don't think
it's very common for components to implement an interface that they also
have as an extension point; does ThemeEngine really *need* to do this to
function? Do your other instances? If so, does it really *need* to
iterate over the extension point in its initializer and not in a lazily
evaluated property?
Anyway, the specifics of this too can be revisited in another thread and at
another time.
> Nonetheless there's a ticket opened somewhere
> in ThemeEnginePlugin issue tracker. If we ever manage to find out a
> generic , clean and simple solution not relying on a core patch , we
> will try to revert our changes and use it once we test everything is
> ok with it . The way I see it that has not happened yet .
FWIW this is exactly the sort of thing that would benefit from a milestone,
keyword or other piece of structured metadata, including the reference to
the ThemeEngine ticket.
> OTOH we *REALLY* needed ThemeEnginePlugin in order to customize web UI
> so , I repeat the question ... what shall we do ? wait 2 more years in
> order to release 0.1.0rc1 ?
No. I did not mean to suggest that removing this core patch should be a
prerequisite to releasing 0.1 -- just that the questions "Is this core
patch necessary?", "What can we do to make it no longer necesssary?" and
"What progress has been made to remove those patches?" should be asked
before the first and every subsequent release, as well as the
meta-questions about the infrastructures and workflows that facilitate
answering those questions. My "-1" referred to the licensing and code
location aspects, and to the fact that these questions had not yet been
raised and discussed, and no more.
Hope this clarifies,
Ethan
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
Hi Ethan !
Thanks for your message . Some comments below.
On 8/2/12, Ethan Jucovy <et...@gmail.com> wrote:
> -1
>
[...]
>
> Specifically, Bloodhound already depends on a patched copy of Trac which
> lives in the Bloodhound SVN repository under
> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and is
> distributed with the release.
yes you are right . Some changes have been needed in order to make
Bloodhound work. Each and every one of them can be considered a last
recourse alternative . We know (or have a good idea) of the
implications of patching Trac source code , and duplicate effort
needed if those patches do not make their way upstream so we try to
avoid doing that . Indeed , if you take a look at Bloodhound plugins
code and pending patches submitted to the issue tracker you'll notice
that many of the APIs have been strongly influenced by the decision of
not to modify Trac source code (if you need a particular example ,
please take a look at #94 and multiproduct plugin ; they both would
require major refactorings of Trac core , but we have been lucky so
far and worked successfully around current limitations)
> This raises a number of questions:
>
> * Some of the files in Bloodhound's modified copy of Trac core contain
> "Licensed to the Apache Software Foundation" headers.
> (trac/utils/tests/introspection.py and trac/util/introspection.py are the
> ones I've noticed, but I didn't grep the repository.)
well I did , and this is what I found (a summary of course ;)
1. a lot of files (e.g. docs) contain Apache word as a reference to httpd
web server so I'll filter that part as I see that content in Trac too
and I consider that mentioning product name this way should
not be a violation of license statement (... and if they are
like I said, please forward your request to trac-dev ML since
they wrote that part , not us) ... so I filtered grep result
set this way
{{{
#!sh
$ grep -r Apache . | grep -v "\.svn" | grep -v "default-pages" | grep Apache
./INSTALL: * A web server capable of executing CGI/FastCGI scripts, or Apache
./trac/htdocs/js/excanvas.js:// Licensed under the Apache License,
Version 2.0 (the "License");
./trac/util/introspection.py:# Licensed to the Apache Software
Foundation (ASF) under one
./trac/util/introspection.py:# to you under the Apache License,
Version 2.0 (the
./trac/util/tests/introspection.py:# Licensed to the Apache Software
Foundation (ASF) under one
./trac/util/tests/introspection.py:# to you under the Apache License,
Version 2.0 (the
./trac/web/main.py: # SCRIPT_URL is an Apache var containing the
URL before URL rewriting
./trac/web/_fcgi.py: # this with Apache's mod_env [not
loaded by default in OS X
./UPGRADE:handler in the Apache HTTPD configuration::
}}}
2. Beyond that , the first file with an Apache license statement is
./trac/htdocs/js/excanvas.js . It was committed to Trac's repos
for the first time in trac:changeset:10330 . It's Google's as
I can see in trac:browser:/trunk/trac/htdocs/js/excanvas.js .
I also noticed this
{{{
#!sh
$ ls -l trac/htdocs/js/excanvas.js
-rwxrwxrwx 1 billgates billgates 18220 2012-07-02 08:50
trac/htdocs/js/excanvas.js
}}}
3. We move forward . The second file is
./trac/util/introspection.py . I think we committed it to
support the case of sub-classing TicketModule and
some other stuff . TBH they are quite unlikely to
be accepted upstream sue to the fact that it
contains helper functions not used by Trac itself ,
in first place , and also their at aimed at doing
something that Trac developer (almost ?) never do
themeselves , and afaicr they do not recommend (i.e.
subclass existing components) . Besides
{{{
#!sh
-rwxrwxrwx 1 billgates billgates 1344 2012-07-04 22:30
trac/util/introspection.py
}}}
4. finally consider the fact that we have applied bigger
modifications on other files and did not change license
headers at all .
so ...
> I think this is
> contrary to previous claims that Bloodhound's developers would keep all
> Trac modifications BSD-licensed,
oh no ! you are not accurate here . My conclusions are :
1. you have one of Google's files (> 10kB) in Trac
repos containing AL v2 icense header .
How many times did you complain about that ?
2. there's another file we introduced in there (< 2kB)
containing code that
2.1 is never going to make its journey upstream
IMO,
2.2 afaics no Trac developer did anything about it .
so my questions are (my curiosity prevails here) :
1. what's the reason for so much noise ?
2. if we suggest a patch upstream containing a whole
new file we did from scratch . Why is it that you
complain about it whereas Google's source code
released under the terms of the same license
is accepted with pleasure ?
<OT>
in any case Gary , would you mind to consider moving that file to
dashboard plugin ?
</OT>
> and that the individual authors would
> retain their copyright over these lines of code, for the sake of keeping
> Trac's BSD license intact for all upstream patches[1].
that's the case even if we had no time yet to announce our patches in
trac-dev ... afaicr
but let's focus on my previous question once again
3. in case we are the original authors (the project I mean)
like in (2) why can't we propose a file with AL v2 header ?
[...]
>
> * What tag/revision of Trac core is the code diverging from? Where is
> this documented?
yes, we need to improve on this . Actually maybe for 0.2.0
> How often do Bloodhound's developers merge in upstream
> changes, and what is their policy for deciding when to merge upstream
> changes?
>
so far afaicr the only update in vendor branch was made in order to
close a ticket related to BatchModify plugin . So if there's no such
policy at the time I suggest this one based on what's happened so far
:
1- at a given time (e.g. project creation) if trac-dev is unstable we
merge trunk right away
2- if there are relevant modifications upstream allowing as to close
a ticket then merge them right away .
3- once stable Trac releases are announced stick to using them
for as long as possible (<= in order to test Bloodhound code
using stable release deployed by Trac users in target servers)
4- if we decide to release a new tarball and it works with latest
Trac stable release , that's the one.
5- goto step 2
... I think this deserves a whole new thread forked from here , if you follow .
> * The patched copy of Trac seems to have a few-hundred-line diff from the
> official Trac distribution. (I'm not sure the best way to measure this.)
> Where are these patches (and their intentions, and the Bloodhound code
> that relies on each patch) being tracked and documented as core patches?
> What procedures are in place to ensure that each core patch is being
> tracked and documented?
>
Gary mentioned something about using subversion vendor branch best
practices for this purpose . The rationale for doing so should be
documented in the issue tracker . Besides every (recent) log message
contains a reference to a ticket number . A tour around the issue
tracker might be all you need . Isn't that enough ?
> * Have all of these patches been submitted upstream to the Trac core
> community?
No , so far we have had no time to do so , but that was on the schedule ;)
> Where are the upstream submissions being tracked and
> documented?
<joke>
objection !
there's no child born yet , there's neither birth date nor a record ,
we all are still innocent your Honor
</joke>
> (I tried several searches on trac.edgewall.org and couldn't
> find any such tickets.) What procedures are in place to ensure that each
> core patch is filed upstream, and to track the upstream status of each core
> patch?
>
it seems to me that not all patches will go upstream , mainly because
some of them will never be committed by trac-dev (due to their quality
standards, policies, etc ...)
> * If the Trac core developers reject a patch or suggest an alternate
> approach, will Bloodhound's developers take that advice and rework their
> own code? What procedures are being developed to ensure that this will
> happen, rather than the expedient route of continuing to rely on a patched
> Trac copy?
>
This already happened and you mention the example below , so , I will
not provide further details .
In general , like I mentioned before , we avoid patching Trac core so
much as possible . If we finally do so then it's a last recourse
decision . That means that the patch is really important for us to get
something done . As a consequence if trac-dev does not accept the
patch we should keep it in there anyways . The only thing I suggest is
to create a ticket in a particular milestone (e.g. upstream_reject) to
watch for this , because there's a chance that e.g. three years later
Trac evolves and fortunately there will be a way to do the same thing
using new or modified APIs .
I hope you can see that this decision does not mean we are evil , at least IMO .
> * It looks like Bloodhound currently depends on three upstream Trac
> plugins -- where are Bloodhound's issues filed against those plugins being
> tracked?
>
afaicr there's no such issue yet . The only one I recall is #74 and it
was fixed by updating Trac's built-in copy in vendor branch . If this
happens then
1. user reports an issue in Bloodhound issue tracker
2. we analyze it and determine if it's an error in third-party plugin
3. we forward the issue to plugin's issue tracker and close
Bloodhound's as wontfix , providing all the details so that
it will be possible for users to follow the discussion in
forwarded ticket page .
4. we are not responsible anymore
... at least that's the way (I think) it should work as long as we do
not include code for third-party plugins in ASF repository and take
responsibility for maintaining it .
> I'm aware of only one instance where an upstream patch was discussed with
> the Trac community so far[5]. In that instance, a Trac developer said the
> relevant plugin code was in error and suggested an alternate approach[6]
> that would patch the faulty plugin code instead of working around it with a
> core patch. This was filed but has not yet been acted on[7], and
> Bloodhound's developers did not all seem to agree that the advice from
> upstream should be followed[8, 9]; instead of patching the plugin code or
> fixing it upstream, the Bloodhound release continues to use the rejected
> core Trac patch.
>
TBH plugin code was not in error , I mean there was no semantic nor
even a programming error . In few words the answer was «we changed
Trac code for a good reason and what everybody used to do before will
not work now . you have to over-complicate your code and stick to our
new policies (<= do not enumerate extension points in component's
initializer if it implements target interface)» . I honestly don't
agree with trac-dev decision so , in the end we decided that such a
situation (i.e. enumerating ExtensionPoint objects in initializers of
classes implementing target interface) will happen quite often in our
code and preferred not to over-complicate plugin code , use locks ,
etc, etc (oh my !) ... Nonetheless there's a ticket opened somewhere
in ThemeEnginePlugin issue tracker. If we ever manage to find out a
generic , clean and simple solution not relying on a core patch , we
will try to revert our changes and use it once we test everything is
ok with it . The way I see it that has not happened yet .
> The plugin in question is well known and hasn't been maintained by its
> original author for more than two years (hence its incompatibility with
> Trac trunk) so this is a good example of why these questions matter.
Exactly . So what shall we do ?
> If
> Bloodhound's development workflows prioritized following advice from Trac
> core and submitted a good patch against ThemeEngine (maintaining a vendor
> branch // patch queue // short-lived fork of the plugin code in the
> meantime) then one of Bloodhound's developers could probably adopt
> maintenance for the plugin through existing Trac community channels pretty
> easily, which would benefit the wider Trac community.
>
That'd be cool if we were 100 people but that's not the case . Myself
, I have enough with my own plugins , and Bloodhound , and ... The
solution indeed must come from the community . We cannot adopt all
hacks and expect to fix them . That's not realistic . Right now
unfortunately we don't have the resources to maintain
ThemeEnginePlugin . Sorry . If somebody just volunteers and we finally
don't need our patch anymore then maybe there's a chance to remove it
after all ... that's not the case now afaics .
OTOH we *REALLY* needed ThemeEnginePlugin in order to customize web UI
so , I repeat the question ... what shall we do ? wait 2 more years in
order to release 0.1.0rc1 ?
[...]
>
> [1]
> http://www.mail-archive.com/bloodhound-dev@incubator.apache.org/msg00003.html
> [2]
> http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201201.mbox/%3C4F07380E.7060505@wandisco.com%3E
> [3] http://osdir.com/ml/trac-dev/2012-01/msg00023.html
> [4]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3C96BC3F76-A04A-4382-9CC1-547CA6757F9C@dslextreme.com%3E
> [5]
> http://old.nabble.com/Create-new-ticket-vs-reopen--9418-(if-necessary--)-td33164546.html
> [6]
> http://old.nabble.com/Re%3A-Create-new-ticket-vs-reopen--9418-%28if-necessary--%29-p33176708.html
> [7] https://issues.apache.org/bloodhound/ticket/27
> [8]
> http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201204.mbox/%3CCAGMZAuPywg_QLUfiL4MEAR-57at22V8Oe=Yhr1+Hy3m8sxOexQ@mail.gmail.com%3E
> [9] http://trac-hacks.org/ticket/9580#comment:3
>
[...]
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Ethan Jucovy <et...@gmail.com>.
-1
(Note: I've been travelling recently without much internet access, and will
continue to be for the next few weeks.)
I haven't seen any significant movement on the Trac<->Bloodhound community
issues discussed during Bloodhound's initial project proposal. The
Bloodhound developers also seem to have backtracked on the specific
resolutions made during the initial discussions, and haven't yet
established any workflows or documentation to ensure good communication
with the Trac community. If these issues are not addressed before the
initial release, Bloodhound's current working code and development
workflows will gain inertia, and increase the risk of a permanent de facto
fork.
Specifically, Bloodhound already depends on a patched copy of Trac which
lives in the Bloodhound SVN repository under
https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ and is
distributed with the release. This raises a number of questions:
* Some of the files in Bloodhound's modified copy of Trac core contain
"Licensed to the Apache Software Foundation" headers.
(trac/utils/tests/introspection.py and trac/util/introspection.py are the
ones I've noticed, but I didn't grep the repository.) I think this is
contrary to previous claims that Bloodhound's developers would keep all
Trac modifications BSD-licensed, and that the individual authors would
retain their copyright over these lines of code, for the sake of keeping
Trac's BSD license intact for all upstream patches[1]. These license
headers should be removed before a release.
* Based on the earlier discussions on the Apache Incubator list, I'm not
sure whether cutting a release that depends on a Trac distribution
maintained by Bloodhound developers in the Apache Incubator's SVN satisfies
ASF's guidelines and policies. The patched Trac distribution should
probably be moved to a public code-hosting site like Sourceforge, Github or
Bitbucket, instead of continuing to live in the ASF SVN. The release
should then point to a tag at that new location for installation, instead
of distributing the patched Trac code with the release itself.
* During the project's initiation the idea of maintaining short-term Trac
patches in a branch-heavy Git repository or Mercurial patch queue was
discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
Why did Bloodhound's developers not take this approach after saying they
would?
* What tag/revision of Trac core is the code diverging from? Where is
this documented? How often do Bloodhound's developers merge in upstream
changes, and what is their policy for deciding when to merge upstream
changes?
* The patched copy of Trac seems to have a few-hundred-line diff from the
official Trac distribution. (I'm not sure the best way to measure this.)
Where are these patches (and their intentions, and the Bloodhound code
that relies on each patch) being tracked and documented as core patches?
What procedures are in place to ensure that each core patch is being
tracked and documented?
* Have all of these patches been submitted upstream to the Trac core
community? Where are the upstream submissions being tracked and
documented? (I tried several searches on trac.edgewall.org and couldn't
find any such tickets.) What procedures are in place to ensure that each
core patch is filed upstream, and to track the upstream status of each core
patch?
* If the Trac core developers reject a patch or suggest an alternate
approach, will Bloodhound's developers take that advice and rework their
own code? What procedures are being developed to ensure that this will
happen, rather than the expedient route of continuing to rely on a patched
Trac copy?
* It looks like Bloodhound currently depends on three upstream Trac
plugins -- where are Bloodhound's issues filed against those plugins being
tracked?
I'm aware of only one instance where an upstream patch was discussed with
the Trac community so far[5]. In that instance, a Trac developer said the
relevant plugin code was in error and suggested an alternate approach[6]
that would patch the faulty plugin code instead of working around it with a
core patch. This was filed but has not yet been acted on[7], and
Bloodhound's developers did not all seem to agree that the advice from
upstream should be followed[8, 9]; instead of patching the plugin code or
fixing it upstream, the Bloodhound release continues to use the rejected
core Trac patch.
The plugin in question is well known and hasn't been maintained by its
original author for more than two years (hence its incompatibility with
Trac trunk) so this is a good example of why these questions matter. If
Bloodhound's development workflows prioritized following advice from Trac
core and submitted a good patch against ThemeEngine (maintaining a vendor
branch // patch queue // short-lived fork of the plugin code in the
meantime) then one of Bloodhound's developers could probably adopt
maintenance for the plugin through existing Trac community channels pretty
easily, which would benefit the wider Trac community.
To be clear, I don't think Bloodhound's initial releas requires a
completely smooth procedure and infrastructure for tracking patches,
submitting upstream contributions, and reworking changes based on upstream
feedback. (Though the specific "technical" questions about licensing and
code location should be addressed now.)
But those questions should be considered part of the release process.
Partly because it's the best/only formal opportunity in the development
cycle to make sure the upstream/downstream workflow is running smoothly.
And also because, after a release is made, inertia will build for just
leaving patches in place as-is instead of waiting for upstream feedback and
potentially rewriting features that are already working in the wild. So I
think it would be more prudent to postpone the initial release until
working first drafts of these knowledge-maintenance/collaboration workflows
have been established among Bloodhound's developers.
-Ethan
[1]
http://www.mail-archive.com/bloodhound-dev@incubator.apache.org/msg00003.html
[2]
http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201201.mbox/%3C4F07380E.7060505@wandisco.com%3E
[3] http://osdir.com/ml/trac-dev/2012-01/msg00023.html
[4]
http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3C96BC3F76-A04A-4382-9CC1-547CA6757F9C@dslextreme.com%3E
[5]
http://old.nabble.com/Create-new-ticket-vs-reopen--9418-(if-necessary--)-td33164546.html
[6]
http://old.nabble.com/Re%3A-Create-new-ticket-vs-reopen--9418-%28if-necessary--%29-p33176708.html
[7] https://issues.apache.org/bloodhound/ticket/27
[8]
http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201204.mbox/%3CCAGMZAuPywg_QLUfiL4MEAR-57at22V8Oe=Yhr1+Hy3m8sxOexQ@mail.gmail.com%3E
[9] http://trac-hacks.org/ticket/9580#comment:3
On Thu, Aug 2, 2012 at 2:14 PM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com>
> wrote:
> >...
> > Please vote:
> > [ ] +1 Release this package as Apache Bloodhound 0.1.0
> > [ ] +0 Don't care
> > [ ] -1 Do not release this package (please explain)
>
> +1 to release.
>
> Changes that I'd suggest for the next release:
>
> * append dependencies' licenses to LICENSE (in addition to their
> reference in NOTICE)
> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
> dir is proper. (and maybe generally simplify; eg. why CHANGES in
> bloodhound_dashboard?)
> * found another NOTICE in doc/html-templates/ (?!)
> * is doc/wireframes supposed to be shipped in the release?
> * found another LICENSE/NOTICE pair in installer/
> * files like bloodhound_dashboard/setup.cfg (and other .ini format
> files like ticket_data.ini) could use a license header (use of RAT
> will find more of these)
> - same with bloodhound_dashboard/macros.py
> - run RAT before 0.2 release
> * in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
> then comment holding the license header comes before the DOCTYPE
> element. not sure that is (formally) allowed. probably should have the
> DOCTYPE, then the comment, then the <div>
> * might be nice to have a top-level README that points to
> installer/README.rst
> * would also be nice to indicate what release/revision of Trac is
> incorporated into this release, along with a notice that local patches
> have been applied. (on that note: has anybody worked to push the local
> changes upstream?)
>
>
> That's all for now. While I think this it is fine to release in this
> shape, I might also suggest incorporating the above changes and
> produce a 0.1 tarball (no RC1 designator) and shoot that out for
> another BH release vote followed by IPMC vote. (the IPMC vote will be
> easier if RAT is run first, but I can beat down any hubbub even on
> this RC1 if you go that route).
>
> On version numbers in general, they are cheap. There is no reason to
> have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
> release it, then make the next one 0.2 or 0.1.1. Never re-use a
> number! ... but there isn't a reason to be so conservative as to make
> a 0.1.0-RC1 tarball. In the long run, you probably want a standard
> triple, so going with 0.1.0 makes sense. If people nuke that proposed
> tarball, then spin up a new one called 0.1.1. As I've mentioned
> before, once 0.1.x is out there, you probably wouldn't patch it at
> this point of BH's lifecycle, and just go straight to 0.2.0 instead.
> (tho I guess if it is a total brown-bag release, you could also do a
> teeny patch and push out 0.1.x+1).
>
> Anyways. Food for thought. Again, I'm +1 on this tarball for release.
>
> Cheers,
> -g
>
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com> wrote:
>...
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
+1 to release.
Changes that I'd suggest for the next release:
* append dependencies' licenses to LICENSE (in addition to their
reference in NOTICE)
* remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
dir is proper. (and maybe generally simplify; eg. why CHANGES in
bloodhound_dashboard?)
* found another NOTICE in doc/html-templates/ (?!)
* is doc/wireframes supposed to be shipped in the release?
* found another LICENSE/NOTICE pair in installer/
* files like bloodhound_dashboard/setup.cfg (and other .ini format
files like ticket_data.ini) could use a license header (use of RAT
will find more of these)
- same with bloodhound_dashboard/macros.py
- run RAT before 0.2 release
* in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
then comment holding the license header comes before the DOCTYPE
element. not sure that is (formally) allowed. probably should have the
DOCTYPE, then the comment, then the <div>
* might be nice to have a top-level README that points to installer/README.rst
* would also be nice to indicate what release/revision of Trac is
incorporated into this release, along with a notice that local patches
have been applied. (on that note: has anybody worked to push the local
changes upstream?)
That's all for now. While I think this it is fine to release in this
shape, I might also suggest incorporating the above changes and
produce a 0.1 tarball (no RC1 designator) and shoot that out for
another BH release vote followed by IPMC vote. (the IPMC vote will be
easier if RAT is run first, but I can beat down any hubbub even on
this RC1 if you go that route).
On version numbers in general, they are cheap. There is no reason to
have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
release it, then make the next one 0.2 or 0.1.1. Never re-use a
number! ... but there isn't a reason to be so conservative as to make
a 0.1.0-RC1 tarball. In the long run, you probably want a standard
triple, so going with 0.1.0 makes sense. If people nuke that proposed
tarball, then spin up a new one called 0.1.1. As I've mentioned
before, once 0.1.x is out there, you probably wouldn't patch it at
this point of BH's lifecycle, and just go straight to 0.2.0 instead.
(tho I guess if it is a total brown-bag release, you could also do a
teeny patch and push out 0.1.x+1).
Anyways. Food for thought. Again, I'm +1 on this tarball for release.
Cheers,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Branko Čibej <br...@wandisco.com>.
On 06.08.2012 12:20, Gary Martin wrote:
> On 08/06/2012 10:55 AM, Branko Čibej wrote:
>> On 06.08.2012 11:40, Gary Martin wrote:
>>> By the way, are there any alternatives to RAT? Perhaps it does not
>>> make so much sense to maintain multiple tools for the same purpose
>>> but, at the same time, it seems a bit of overkill for a project that
>>> uses neither Maven or Java for anything else.
>>>
>>> Well, just wondering really.
>> I'm not aware of any such alternative. I agree with the sentiment that
>> RAT is somewhat top-heavy in this context, but then, using it to check
>> compliance with ASF guidelines doesn't really make it part of the
>> project. And by the time Bloodhound graduates, it's pretty much assumed
>> that the PMC is able to control what goes in without requiring a RAT
>> report before every release.
>>
>> -- Brane
>>
>
> Well, I would expect the kind of checking that RAT provides would
> always give piece of mind, if not being strictly necessary once
> everything is in a good state. The question is more whether just those
> few steps will deter people from running the tool for themselves. That
> might be considered a small barrier to participation.
I don't think it would ever make sense to require contributors to run
RAT, just as it doesn't make sense to ask them to test their changes on
more than the platform they're developing on.
> Really I am just thinking of my own temporary inconvenience of course.
> I should probably just keep quiet and just put it into an automated
> release testing mechanism. Perhaps we can run this on a buildbot slave
> so that the output from RAT can be linked to and we will have
> confidence in how it is run.
That sound like a good plan.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 7, 2012 at 3:46 AM, Gavin McDonald <ga...@16degrees.com.au> wrote:
>...
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: Tuesday, 7 August 2012 3:14 PM
>> To: bloodhound-dev@incubator.apache.org
>> Cc: Gavin McDonald
>> Subject: Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
>>
>> Hmm. Looks like the page is a bit busted:
>> http://ci.apache.org/projects/rat-master-summary.html
>>
>> Here's the info on the Buildbot service here at Apache:
>> http://ci.apache.org/buildbot.html
>>
>> cc: Gavin for an update on the RAT rollup and what he may need for help to
>> fix that up.
>
> Thanks
>
> Fixed.
Sweet. Looks like svn has some stuff to look at...
> I had moved the public_html dir containing the files that 'find' needed but
> negated to
> Add a -L option to follow the symlink boundary.
>
> I will also sort out adding Bloodhound to Rat so leave that to me.
> Do we have a excludes file in place or shall I start one?
Nothing started yet, so please feel free!
Cheers,
-g
RE: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Tuesday, 7 August 2012 3:14 PM
> To: bloodhound-dev@incubator.apache.org
> Cc: Gavin McDonald
> Subject: Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
>
> Hmm. Looks like the page is a bit busted:
> http://ci.apache.org/projects/rat-master-summary.html
>
> Here's the info on the Buildbot service here at Apache:
> http://ci.apache.org/buildbot.html
>
> cc: Gavin for an update on the RAT rollup and what he may need for help to
> fix that up.
Thanks
Fixed.
I had moved the public_html dir containing the files that 'find' needed but
negated to
Add a -L option to follow the symlink boundary.
I will also sort out adding Bloodhound to Rat so leave that to me.
Do we have a excludes file in place or shall I start one?
Gav...
>
> Cheers,
> -g
>
> On Mon, Aug 6, 2012 at 10:43 PM, Olemis Lang <ol...@gmail.com> wrote:
> > oh!
> > please, provide details to take a look ... if possible of course
> > ;)
> >
> > On 8/6/12, Greg Stein <gs...@gmail.com> wrote:
> >> On Aug 6, 2012 6:21 AM, "Gary Martin" <ga...@wandisco.com>
> wrote:
> >>>...
> >>> Really I am just thinking of my own temporary inconvenience of
> >>>course. I
> >> should probably just keep quiet and just put it into an automated
> >> release testing mechanism. Perhaps we can run this on a buildbot
> >> slave so that the output from RAT can be linked to and we will have
> >> confidence in how it is run.
> >>
> >> There is a RAT buildbot already. File a ticket with infra, pointing
> >> to trunk and our excludes file, and Bloodhound will be looped in.
> >> IIRC, there is even a nifty webpage that shows the output.
> >>
> >> Cheer,
> >> -g
> >>
> >
> >
> > --
> > Regards,
> >
> > Olemis.
> >
> > Blog ES: http://simelo-es.blogspot.com/ Blog EN:
> > http://simelo-en.blogspot.com/
> >
> > Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
Hmm. Looks like the page is a bit busted:
http://ci.apache.org/projects/rat-master-summary.html
Here's the info on the Buildbot service here at Apache:
http://ci.apache.org/buildbot.html
cc: Gavin for an update on the RAT rollup and what he may need for
help to fix that up.
Cheers,
-g
On Mon, Aug 6, 2012 at 10:43 PM, Olemis Lang <ol...@gmail.com> wrote:
> oh!
> please, provide details to take a look ... if possible of course
> ;)
>
> On 8/6/12, Greg Stein <gs...@gmail.com> wrote:
>> On Aug 6, 2012 6:21 AM, "Gary Martin" <ga...@wandisco.com> wrote:
>>>...
>>> Really I am just thinking of my own temporary inconvenience of course. I
>> should probably just keep quiet and just put it into an automated release
>> testing mechanism. Perhaps we can run this on a buildbot slave so that the
>> output from RAT can be linked to and we will have confidence in how it is
>> run.
>>
>> There is a RAT buildbot already. File a ticket with infra, pointing to
>> trunk and our excludes file, and Bloodhound will be looped in. IIRC, there
>> is even a nifty webpage that shows the output.
>>
>> Cheer,
>> -g
>>
>
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Olemis Lang <ol...@gmail.com>.
oh!
please, provide details to take a look ... if possible of course
;)
On 8/6/12, Greg Stein <gs...@gmail.com> wrote:
> On Aug 6, 2012 6:21 AM, "Gary Martin" <ga...@wandisco.com> wrote:
>>...
>> Really I am just thinking of my own temporary inconvenience of course. I
> should probably just keep quiet and just put it into an automated release
> testing mechanism. Perhaps we can run this on a buildbot slave so that the
> output from RAT can be linked to and we will have confidence in how it is
> run.
>
> There is a RAT buildbot already. File a ticket with infra, pointing to
> trunk and our excludes file, and Bloodhound will be looped in. IIRC, there
> is even a nifty webpage that shows the output.
>
> Cheer,
> -g
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Greg Stein <gs...@gmail.com>.
On Aug 6, 2012 6:21 AM, "Gary Martin" <ga...@wandisco.com> wrote:
>...
> Really I am just thinking of my own temporary inconvenience of course. I
should probably just keep quiet and just put it into an automated release
testing mechanism. Perhaps we can run this on a buildbot slave so that the
output from RAT can be linked to and we will have confidence in how it is
run.
There is a RAT buildbot already. File a ticket with infra, pointing to
trunk and our excludes file, and Bloodhound will be looped in. IIRC, there
is even a nifty webpage that shows the output.
Cheer,
-g
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
On 08/06/2012 10:55 AM, Branko Čibej wrote:
> On 06.08.2012 11:40, Gary Martin wrote:
>> By the way, are there any alternatives to RAT? Perhaps it does not
>> make so much sense to maintain multiple tools for the same purpose
>> but, at the same time, it seems a bit of overkill for a project that
>> uses neither Maven or Java for anything else.
>>
>> Well, just wondering really.
> I'm not aware of any such alternative. I agree with the sentiment that
> RAT is somewhat top-heavy in this context, but then, using it to check
> compliance with ASF guidelines doesn't really make it part of the
> project. And by the time Bloodhound graduates, it's pretty much assumed
> that the PMC is able to control what goes in without requiring a RAT
> report before every release.
>
> -- Brane
>
Well, I would expect the kind of checking that RAT provides would always
give piece of mind, if not being strictly necessary once everything is
in a good state. The question is more whether just those few steps will
deter people from running the tool for themselves. That might be
considered a small barrier to participation.
Really I am just thinking of my own temporary inconvenience of course. I
should probably just keep quiet and just put it into an automated
release testing mechanism. Perhaps we can run this on a buildbot slave
so that the output from RAT can be linked to and we will have confidence
in how it is run.
Cheers,
Gary
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Branko Čibej <br...@wandisco.com>.
On 06.08.2012 11:40, Gary Martin wrote:
> By the way, are there any alternatives to RAT? Perhaps it does not
> make so much sense to maintain multiple tools for the same purpose
> but, at the same time, it seems a bit of overkill for a project that
> uses neither Maven or Java for anything else.
>
> Well, just wondering really.
I'm not aware of any such alternative. I agree with the sentiment that
RAT is somewhat top-heavy in this context, but then, using it to check
compliance with ASF guidelines doesn't really make it part of the
project. And by the time Bloodhound graduates, it's pretty much assumed
that the PMC is able to control what goes in without requiring a RAT
report before every release.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Gary Martin <ga...@wandisco.com>.
On 08/06/2012 07:12 AM, Hyrum K Wright wrote:
> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com> wrote:
>> Hi everyone,
>>
>> I hope that this is not premature but as the conversation on the related
>> [PROPOSAL] thread has died down, I would like to initiate the vote for
>> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
>> the first release of the project and is an important step that I hope will
>> generate interest in the project and help the community to grow.
>>
>> The release candidate this vote relates to provides:
>>
>> * A patched version of Trac
>> * A new dashboard view with the dashboard style unifying views of
>> tickets, milestones and the user's dashboard.
>> * A re-theming of the interface to use bootstrap
>> * Preliminary multi-product support as a step towards allowing the
>> tracking of multiple distinct products (or projects) in a single
>> environment
>> * Simplified installation with the inclusion of a number of plugins as
>> standard.
>>
>> As an initial release, of particular importance is that we have taken proper
>> notice of licensing of code produced as part of this project and the proper
>> acknowledgement of external work packaged with it.
>>
>> The release candidate artifacts consist of source release as a tar.gz
>> archive along with the associated MD5 and GPG signature. These can be found
>> at: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>>
>> Please vote:
>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>>
>> The vote is open for 72 hours and, if successful, will be followed by a vote
>> on general@incubator for a further 72 hours.
> I know I'm late to the party, but +1 (binding).
>
> I have not evaluated the technical content of the tarball, but have
> looked to ensure it complies with ASF policies. (Aside: it would be
> nice to have an appropriate excludes file for the RAT tool, but that
> shouldn't hold up this release.)
>
> Good work and congrats!
>
> Your absentee mentor,
> -Hyrum
Thanks for that. I will look into it.
By the way, are there any alternatives to RAT? Perhaps it does not make
so much sense to maintain multiple tools for the same purpose but, at
the same time, it seems a bit of overkill for a project that uses
neither Maven or Java for anything else.
Well, just wondering really.
Cheers,
Gary
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <ga...@wandisco.com> wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the related
> [PROPOSAL] thread has died down, I would like to initiate the vote for
> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
> the first release of the project and is an important step that I hope will
> generate interest in the project and help the community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins as
> standard.
>
> As an initial release, of particular importance is that we have taken proper
> notice of licensing of code produced as part of this project and the proper
> acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be found
> at: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by a vote
> on general@incubator for a further 72 hours.
I know I'm late to the party, but +1 (binding).
I have not evaluated the technical content of the tarball, but have
looked to ensure it complies with ASF policies. (Aside: it would be
nice to have an appropriate excludes file for the RAT tool, but that
shouldn't hold up this release.)
Good work and congrats!
Your absentee mentor,
-Hyrum
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Posted by Mark Poole <mp...@apache.org>.
+1
On Wed, Jul 25, 2012 at 7:18 PM, Gary Martin <ga...@wandisco.com>wrote:
> Hi everyone,
>
> I hope that this is not premature but as the conversation on the related
> [PROPOSAL] thread has died down, I would like to initiate the vote for
> releasing Apache Bloodhound 0.1.0 (incubating). If successful this will be
> the first release of the project and is an important step that I hope will
> generate interest in the project and help the community to grow.
>
> The release candidate this vote relates to provides:
>
> * A patched version of Trac
> * A new dashboard view with the dashboard style unifying views of
> tickets, milestones and the user's dashboard.
> * A re-theming of the interface to use bootstrap
> * Preliminary multi-product support as a step towards allowing the
> tracking of multiple distinct products (or projects) in a single
> environment
> * Simplified installation with the inclusion of a number of plugins as
> standard.
>
> As an initial release, of particular importance is that we have taken
> proper notice of licensing of code produced as part of this project and the
> proper acknowledgement of external work packaged with it.
>
> The release candidate artifacts consist of source release as a tar.gz
> archive along with the associated MD5 and GPG signature. These can be found
> at: https://dist.apache.org/repos/**dist/dev/incubator/bloodhound/<https://dist.apache.org/repos/dist/dev/incubator/bloodhound/>
>
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> The vote is open for 72 hours and, if successful, will be followed by a
> vote on general@incubator for a further 72 hours.
>