You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2013/05/08 16:58:23 UTC

Re: How do we handle an Incubator release

I wonder if maybe we should do a simple first release (e.g. tarball of the whole
thing, if that's the easiest option).  Then we could get our first release out
sooner.  We can also work through any licensing/procedure concerns on the first
release(s) and not have to worry about technical complexities at the same time.

On 4/18/13 2:24 PM, Dave Brondsema wrote:
> From a technical standpoint, many of the packages like ForgeBlog, ForgeGit,
> ForgeTracker, etc are independent and could be packaged separately.  But I'm
> having trouble visualizing what would be in our core package.  The "Allura"
> python package can't run on its own, it is dependent on the ForgeWiki (as a
> default tool for new users).  And some top-level files and folders are needed
> too (e.g. solr_config/ and maybe requirements*.txt)  The NoWarnings and
> AlluraTesting packages are needed for running the Allura package tests too.  So
> not that it can't be done, but delivering each python package as its own tarball
> could require some effort.  I suppose that may be something we have to go
> through anyay to make pypi releases work.
> 
> Also if someone wanted to install many or all the Allura tools, it would be more
> convenient to have a whole package rather than over a dozen separate packages.
> 
> On 4/18/13 11:54 AM, Peter Hartmann wrote:
>> As part of our graduation process from Incubator, we (Allura contributors) must
>> demonstrate our ability to make an official release, in line with ASF
>> guidelines. It seems that throughout last year all technical and legal obstacles
>> have been removed and we're ready to start working on getting a release out. As
>> per https://sourceforge.net/p/allura/tickets/3905/ we also want to make a
>> release on PyPI and somehow synchronizing these two releases would be a sane
>> thing to do.
>>
>> The most basic way we may do Incubator release is simply get a repository
>> tarball on a public Apache server. This has the merits of being very
>> straightforward and it seems to be most popular option among other projects.
>>
>> I've proposed on IRC that we may also release every module that forms Allura
>> codebase as a separate tarball. The rationale behind this is that in process of
>> making a release on PyPI, each module will have to be packaged separately
>> anyways. PyPI/pip/setuptools also can work with tarballs and by keeping a single
>> set of distributed archives we can avoid possible confusion on that part. Same
>> tarballs would be uploaded to PyPI and Apache servers.
>>
>> It would be an unusal way to do things, but doesn't seem to conflict the
>> guidelines: http://incubator.apache.org/guides/releasemanagement.html
>>
>> Release process can of course be modified later on, and the way we make releases
>> is important enough to be discussed by whole community here. Anyone's input is
>> welcome, so are any new proposals on the matter.
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: How do we handle an Incubator release

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Cory Johns wrote on Thu, Aug 08, 2013 at 11:36:15 -0400:
> We need to create the KEYS file with the keys of anyone who will be

Or you could use https://people.apache.org/keys/group/allura.asc.
It will be created once:

- An allura= group is added to the svn authz file
- At least one member of that group adds a key to https://id.apache.org/

Daniel

> authorized to sign a release,

Re: How do we handle an Incubator release

Posted by Dave Brondsema <db...@slashdotmedia.com>.
On Thu, Aug 8, 2013 at 12:10 PM, Rich Bowen <rb...@rcbowen.com> wrote:

> On 08/06/2013 10:38 AM, Cory Johns wrote:
>
>> I think so.  We have a rat build passing on Jenkins, and the license
>> issues
>> are all resolved, Dave has access to people.apache.org to set up the
>> directory and upload the file, Dave and I have keys (
>> http://pgp.mit.edu:11371/pks/**lookup?op=vindex&search=**
>> 0x56F0526F9BB3CE70<http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70>and
>> http://pgp.mit.edu:11371/pks/**lookup?op=vindex&search=**
>> 0xDB6E071B449C78B1respectively<http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xDB6E071B449C78B1respectively>
>> **)
>> that should be ok for signing (though mine needs a bit of
>> building up on the web of trust), and there are no other hurdles that I
>> can
>> come up with to creating a tarball of the Allura source, signing it, and
>> putting it up.
>>
>
> I don't know that I'd ever do a release, but I'm at
> http://pgp.mit.edu:11371/pks/**lookup?op=vindex&search=**
> 0x5CFD37FACC78C893<http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x5CFD37FACC78C893>and I'm fairly well connected. And it looks like I signed Dave's key in
> 2004. Were you at ApacheCon in Las Vegas that year?
>
>
>
Ohio Linuxfest I think :)



>
>
> --
> Rich Bowen
> rbowen@rcbowen.com
> Shosholoza
>
>


-- 
Dave Brondsema
Principal Software Engineer - sourceforge.net
Dice Holdings, Inc.

Re: How do we handle an Incubator release

Posted by Rich Bowen <rb...@rcbowen.com>.
On 08/06/2013 10:38 AM, Cory Johns wrote:
> I think so.  We have a rat build passing on Jenkins, and the license issues
> are all resolved, Dave has access to people.apache.org to set up the
> directory and upload the file, Dave and I have keys (
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70 and
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xDB6E071B449C78B1respectively)
> that should be ok for signing (though mine needs a bit of
> building up on the web of trust), and there are no other hurdles that I can
> come up with to creating a tarball of the Allura source, signing it, and
> putting it up.

I don't know that I'd ever do a release, but I'm at 
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x5CFD37FACC78C893 
and I'm fairly well connected. And it looks like I signed Dave's key in 
2004. Were you at ApacheCon in Las Vegas that year?



-- 
Rich Bowen
rbowen@rcbowen.com
Shosholoza


Re: How do we handle an Incubator release

Posted by Cory Johns <cj...@slashdotmedia.com>.
We need to create the KEYS file with the keys of anyone who will be
authorized to sign a release, so anyone who wants to be able to make a
release should provide a link to their key.

Peter, do you have a key up that we can include?


On Tue, Aug 6, 2013 at 10:52 AM, Dave Brondsema <
dbrondsema@slashdotmedia.com> wrote:

> On http://incubator.apache.org/projects/allura.html we've got some items
> under "Copyright" and "Verify distribution rights" that we haven't marked
> as complete, but they are.  I'll update those shortly.
>
>
> On Tue, Aug 6, 2013 at 10:38 AM, Cory Johns <cjohns@slashdotmedia.com
> >wrote:
>
> > I think so.  We have a rat build passing on Jenkins, and the license
> issues
> > are all resolved, Dave has access to people.apache.org to set up the
> > directory and upload the file, Dave and I have keys (
> >
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70and
> >
> >
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xDB6E071B449C78B1respectively
> > )
> > that should be ok for signing (though mine needs a bit of
> > building up on the web of trust), and there are no other hurdles that I
> can
> > come up with to creating a tarball of the Allura source, signing it, and
> > putting it up.
> >
> > For release docs, we will want to create an initial skeleton CHANGELOG.
>  We
> > also discussed changing README.markdown to INSTALL.markdown and creating
> a
> > separate README file.  We also have the generated docs up at
> > http://allura.sourceforge.net/docs/
> >
> > Is there anything else I'm missing?
> >
> >
> > On Tue, Aug 6, 2013 at 9:49 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> >
> > > On 08/05/2013 03:01 PM, Peter Hartmann wrote:
> > >
> > >> 2013/8/5 Rich Bowen <rb...@rcbowen.com>
> > >>
> > >>  On 07/25/2013 08:27 PM, Dave Brondsema wrote:
> > >>>
> > >>>  I'm not aware of any blockers.  I think it might be nice to rename
> our
> > >>>> README to INSTALL, and create a README which is a short summary of
> > what
> > >>>> Allura does, plus a URL or two for folks to find more info.  I don't
> > >>>> think
> > >>>> its critical though.
> > >>>>
> > >>>>
> > >>>>
> > >>>>  How are we going on this? Are we going to be able to have a release
> > by
> > >>> our
> > >>> next board report?
> > >>>
> > >>>
> > >>>  We may try. When is it coming?
> > >>
> > >>  http://incubator.apache.org/**projects/allura.html<
> > http://incubator.apache.org/projects/allura.html>shows that we reported
> > in March - looks like we also reported in June -
> > > http://wiki.apache.org/**incubator/June2013<
> > http://wiki.apache.org/incubator/June2013>- but the page hasn't been
> > updated. So we report in September. That gives
> > > us one month from today, roughly, to do this. Doable?
> > >
> > >
> > > --
> > > Rich Bowen
> > > rbowen@rcbowen.com
> > > Shosholoza
> > >
> > >
> >
>
>
>
> --
> Dave Brondsema
> Principal Software Engineer - sourceforge.net
> Dice Holdings, Inc.
>

Re: How do we handle an Incubator release

Posted by Dave Brondsema <db...@slashdotmedia.com>.
On http://incubator.apache.org/projects/allura.html we've got some items
under "Copyright" and "Verify distribution rights" that we haven't marked
as complete, but they are.  I'll update those shortly.


On Tue, Aug 6, 2013 at 10:38 AM, Cory Johns <cj...@slashdotmedia.com>wrote:

> I think so.  We have a rat build passing on Jenkins, and the license issues
> are all resolved, Dave has access to people.apache.org to set up the
> directory and upload the file, Dave and I have keys (
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70and
>
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xDB6E071B449C78B1respectively
> )
> that should be ok for signing (though mine needs a bit of
> building up on the web of trust), and there are no other hurdles that I can
> come up with to creating a tarball of the Allura source, signing it, and
> putting it up.
>
> For release docs, we will want to create an initial skeleton CHANGELOG.  We
> also discussed changing README.markdown to INSTALL.markdown and creating a
> separate README file.  We also have the generated docs up at
> http://allura.sourceforge.net/docs/
>
> Is there anything else I'm missing?
>
>
> On Tue, Aug 6, 2013 at 9:49 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>
> > On 08/05/2013 03:01 PM, Peter Hartmann wrote:
> >
> >> 2013/8/5 Rich Bowen <rb...@rcbowen.com>
> >>
> >>  On 07/25/2013 08:27 PM, Dave Brondsema wrote:
> >>>
> >>>  I'm not aware of any blockers.  I think it might be nice to rename our
> >>>> README to INSTALL, and create a README which is a short summary of
> what
> >>>> Allura does, plus a URL or two for folks to find more info.  I don't
> >>>> think
> >>>> its critical though.
> >>>>
> >>>>
> >>>>
> >>>>  How are we going on this? Are we going to be able to have a release
> by
> >>> our
> >>> next board report?
> >>>
> >>>
> >>>  We may try. When is it coming?
> >>
> >>  http://incubator.apache.org/**projects/allura.html<
> http://incubator.apache.org/projects/allura.html>shows that we reported
> in March - looks like we also reported in June -
> > http://wiki.apache.org/**incubator/June2013<
> http://wiki.apache.org/incubator/June2013>- but the page hasn't been
> updated. So we report in September. That gives
> > us one month from today, roughly, to do this. Doable?
> >
> >
> > --
> > Rich Bowen
> > rbowen@rcbowen.com
> > Shosholoza
> >
> >
>



-- 
Dave Brondsema
Principal Software Engineer - sourceforge.net
Dice Holdings, Inc.

Re: How do we handle an Incubator release

Posted by Cory Johns <cj...@slashdotmedia.com>.
I think so.  We have a rat build passing on Jenkins, and the license issues
are all resolved, Dave has access to people.apache.org to set up the
directory and upload the file, Dave and I have keys (
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70 and
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xDB6E071B449C78B1respectively)
that should be ok for signing (though mine needs a bit of
building up on the web of trust), and there are no other hurdles that I can
come up with to creating a tarball of the Allura source, signing it, and
putting it up.

For release docs, we will want to create an initial skeleton CHANGELOG.  We
also discussed changing README.markdown to INSTALL.markdown and creating a
separate README file.  We also have the generated docs up at
http://allura.sourceforge.net/docs/

Is there anything else I'm missing?


On Tue, Aug 6, 2013 at 9:49 AM, Rich Bowen <rb...@rcbowen.com> wrote:

> On 08/05/2013 03:01 PM, Peter Hartmann wrote:
>
>> 2013/8/5 Rich Bowen <rb...@rcbowen.com>
>>
>>  On 07/25/2013 08:27 PM, Dave Brondsema wrote:
>>>
>>>  I'm not aware of any blockers.  I think it might be nice to rename our
>>>> README to INSTALL, and create a README which is a short summary of what
>>>> Allura does, plus a URL or two for folks to find more info.  I don't
>>>> think
>>>> its critical though.
>>>>
>>>>
>>>>
>>>>  How are we going on this? Are we going to be able to have a release by
>>> our
>>> next board report?
>>>
>>>
>>>  We may try. When is it coming?
>>
>>  http://incubator.apache.org/**projects/allura.html<http://incubator.apache.org/projects/allura.html>shows that we reported in March - looks like we also reported in June -
> http://wiki.apache.org/**incubator/June2013<http://wiki.apache.org/incubator/June2013>- but the page hasn't been updated. So we report in September. That gives
> us one month from today, roughly, to do this. Doable?
>
>
> --
> Rich Bowen
> rbowen@rcbowen.com
> Shosholoza
>
>

Re: How do we handle an Incubator release

Posted by Rich Bowen <rb...@rcbowen.com>.
On 08/05/2013 03:01 PM, Peter Hartmann wrote:
> 2013/8/5 Rich Bowen <rb...@rcbowen.com>
>
>> On 07/25/2013 08:27 PM, Dave Brondsema wrote:
>>
>>> I'm not aware of any blockers.  I think it might be nice to rename our
>>> README to INSTALL, and create a README which is a short summary of what
>>> Allura does, plus a URL or two for folks to find more info.  I don't think
>>> its critical though.
>>>
>>>
>>>
>> How are we going on this? Are we going to be able to have a release by our
>> next board report?
>>
>>
> We may try. When is it coming?
>
http://incubator.apache.org/projects/allura.html shows that we reported 
in March - looks like we also reported in June - 
http://wiki.apache.org/incubator/June2013 - but the page hasn't been 
updated. So we report in September. That gives us one month from today, 
roughly, to do this. Doable?

-- 
Rich Bowen
rbowen@rcbowen.com
Shosholoza


Re: How do we handle an Incubator release

Posted by Peter Hartmann <ma...@gmail.com>.
2013/8/5 Rich Bowen <rb...@rcbowen.com>

> On 07/25/2013 08:27 PM, Dave Brondsema wrote:
>
>> I'm not aware of any blockers.  I think it might be nice to rename our
>> README to INSTALL, and create a README which is a short summary of what
>> Allura does, plus a URL or two for folks to find more info.  I don't think
>> its critical though.
>>
>>
>>
>
> How are we going on this? Are we going to be able to have a release by our
> next board report?
>
>
We may try. When is it coming?

Re: How do we handle an Incubator release

Posted by Rich Bowen <rb...@rcbowen.com>.
On 07/25/2013 08:27 PM, Dave Brondsema wrote:
> I'm not aware of any blockers.  I think it might be nice to rename our
> README to INSTALL, and create a README which is a short summary of what
> Allura does, plus a URL or two for folks to find more info.  I don't think
> its critical though.
>
>


How are we going on this? Are we going to be able to have a release by 
our next board report?

-- 
Rich Bowen
rbowen@rcbowen.com
Shosholoza


Re: How do we handle an Incubator release

Posted by Dave Brondsema <db...@slashdotmedia.com>.
I'm not aware of any blockers.  I think it might be nice to rename our
README to INSTALL, and create a README which is a short summary of what
Allura does, plus a URL or two for folks to find more info.  I don't think
its critical though.


On Wed, Jul 24, 2013 at 4:11 PM, Cory Johns <cj...@slashdotmedia.com>wrote:

> Hey all.
>
> To move forward with this, I have replaced the unicode_test.txt file with
> one I generated myself, and added a license on it.
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=blob;f=Allura/allura/tests/data/unicode_test.txt;h=be7f2d87c7e4ba20ec972fab6067eff9193d2a61;hb=70d4cdb35fce84eea8c33d06ea355aae88a2950f
>
> With `rat` passing on Allura now, is there anything else blocking us from
> moving forward with this release?
>
> Peter, I know you haven't been able to work on this of late, and we very
> much appreciate your help.  If you can't recall anything else outstanding,
> I would like to perhaps take over and move forward with the final steps.
>
>
> Thanks,
> Cory
>
>
> On Thu, May 23, 2013 at 5:46 PM, Dave Brondsema <da...@brondsema.net>
> wrote:
>
> > On 5/23/13 5:10 PM, Peter Hartmann wrote:
> > > On 23.05.2013 21:56, Dave Brondsema wrote:
> > >> To help us move along towards the release, I ran the Release Audit
> Tool
> > again
> > >> and fixed up some missing headers and added .  They were pretty
> trivial
> > changes
> > >> so I did them on master, they can be reviewed here in case I did
> > anything wrong:
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
> > >>
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
> > >>
> > >>
> > >> After that, I was left with just one file without license info:
> > >> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do
> > with that.
> > >> It looks like it was sourced from somewhere else and I couldn't find a
> > license
> > >> for it.  But it's just test data, so maybe it doesn't need a license,
> > or maybe
> > >> we can remove the test that uses it.  Thoughts?
> > > Hey Dave. I had a real tough week, so I haven't really made much work
> on
> > that.
> > > My apologies.
> > >
> > > I did some heavy research on that file while doing a set-up for RAT and
> > initial
> > > audit. In fact, one software package has removed it, due to the
> > statement on
> > > author's website:
> > >
> >
> http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt
> > >
> > >
> > > However, the file is distributed along with an Unicode fonts set, and
> > here's
> > > what author has to say about it:
> > >
> > >> The copyright status of these fonts remains the same as for the
> > original fonts
> > > in the X11 distribution
> > >
> > > http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
> > >
> > > And the fonts are under public domain (copyright information is
> > available in
> > > each individual .bdf file). As per ASF guidelines, public domain is
> > handled by
> > > adding an attribution line to NOTICE. Don't really know why I haven't
> > done it
> > > back then.
> > >
> >
> > Cool, good info.  If we want to keep it simple, we could remove it pretty
> > easily
> > too.  It's only used one test, in Allura/allura/tests/test_helpers.py  We
> > could
> > easily test with simpler file that we create
> >
> > And FYI, I ran 'rat' on another server recently (our internal CI build)
> > and it
> > thought unicode_test.txt was binary.
> >
> >
> > --
> > Dave Brondsema : dave@brondsema.net
> > http://www.brondsema.net : personal
> > http://www.splike.com : programming
> >               <><
> >
>



-- 
Dave Brondsema
Principal Software Engineer - sourceforge.net
Dice Holdings, Inc.

Re: How do we handle an Incubator release

Posted by Cory Johns <cj...@slashdotmedia.com>.
Hey all.

To move forward with this, I have replaced the unicode_test.txt file with
one I generated myself, and added a license on it.

https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=blob;f=Allura/allura/tests/data/unicode_test.txt;h=be7f2d87c7e4ba20ec972fab6067eff9193d2a61;hb=70d4cdb35fce84eea8c33d06ea355aae88a2950f

With `rat` passing on Allura now, is there anything else blocking us from
moving forward with this release?

Peter, I know you haven't been able to work on this of late, and we very
much appreciate your help.  If you can't recall anything else outstanding,
I would like to perhaps take over and move forward with the final steps.


Thanks,
Cory


On Thu, May 23, 2013 at 5:46 PM, Dave Brondsema <da...@brondsema.net> wrote:

> On 5/23/13 5:10 PM, Peter Hartmann wrote:
> > On 23.05.2013 21:56, Dave Brondsema wrote:
> >> To help us move along towards the release, I ran the Release Audit Tool
> again
> >> and fixed up some missing headers and added .  They were pretty trivial
> changes
> >> so I did them on master, they can be reviewed here in case I did
> anything wrong:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
> >>
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
> >>
> >>
> >> After that, I was left with just one file without license info:
> >> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do
> with that.
> >> It looks like it was sourced from somewhere else and I couldn't find a
> license
> >> for it.  But it's just test data, so maybe it doesn't need a license,
> or maybe
> >> we can remove the test that uses it.  Thoughts?
> > Hey Dave. I had a real tough week, so I haven't really made much work on
> that.
> > My apologies.
> >
> > I did some heavy research on that file while doing a set-up for RAT and
> initial
> > audit. In fact, one software package has removed it, due to the
> statement on
> > author's website:
> >
> http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt
> >
> >
> > However, the file is distributed along with an Unicode fonts set, and
> here's
> > what author has to say about it:
> >
> >> The copyright status of these fonts remains the same as for the
> original fonts
> > in the X11 distribution
> >
> > http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
> >
> > And the fonts are under public domain (copyright information is
> available in
> > each individual .bdf file). As per ASF guidelines, public domain is
> handled by
> > adding an attribution line to NOTICE. Don't really know why I haven't
> done it
> > back then.
> >
>
> Cool, good info.  If we want to keep it simple, we could remove it pretty
> easily
> too.  It's only used one test, in Allura/allura/tests/test_helpers.py  We
> could
> easily test with simpler file that we create
>
> And FYI, I ran 'rat' on another server recently (our internal CI build)
> and it
> thought unicode_test.txt was binary.
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Re: How do we handle an Incubator release

Posted by Dave Brondsema <da...@brondsema.net>.
On 5/23/13 5:10 PM, Peter Hartmann wrote:
> On 23.05.2013 21:56, Dave Brondsema wrote:
>> To help us move along towards the release, I ran the Release Audit Tool again
>> and fixed up some missing headers and added .  They were pretty trivial changes
>> so I did them on master, they can be reviewed here in case I did anything wrong:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
>>
>>
>> After that, I was left with just one file without license info:
>> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
>> It looks like it was sourced from somewhere else and I couldn't find a license
>> for it.  But it's just test data, so maybe it doesn't need a license, or maybe
>> we can remove the test that uses it.  Thoughts?
> Hey Dave. I had a real tough week, so I haven't really made much work on that.
> My apologies.
> 
> I did some heavy research on that file while doing a set-up for RAT and initial
> audit. In fact, one software package has removed it, due to the statement on
> author's website:
> http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt
> 
> 
> However, the file is distributed along with an Unicode fonts set, and here's
> what author has to say about it:
> 
>> The copyright status of these fonts remains the same as for the original fonts
> in the X11 distribution
> 
> http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
> 
> And the fonts are under public domain (copyright information is available in
> each individual .bdf file). As per ASF guidelines, public domain is handled by
> adding an attribution line to NOTICE. Don't really know why I haven't done it
> back then.
> 

Cool, good info.  If we want to keep it simple, we could remove it pretty easily
too.  It's only used one test, in Allura/allura/tests/test_helpers.py  We could
easily test with simpler file that we create

And FYI, I ran 'rat' on another server recently (our internal CI build) and it
thought unicode_test.txt was binary.


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: How do we handle an Incubator release

Posted by Peter Hartmann <ma...@gmail.com>.
On 23.05.2013 21:56, Dave Brondsema wrote:
> To help us move along towards the release, I ran the Release Audit Tool again
> and fixed up some missing headers and added .  They were pretty trivial changes
> so I did them on master, they can be reviewed here in case I did anything wrong:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
>
> After that, I was left with just one file without license info:
> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
> It looks like it was sourced from somewhere else and I couldn't find a license
> for it.  But it's just test data, so maybe it doesn't need a license, or maybe
> we can remove the test that uses it.  Thoughts?
Hey Dave. I had a real tough week, so I haven't really made much work on 
that. My apologies.

I did some heavy research on that file while doing a set-up for RAT and 
initial audit. In fact, one software package has removed it, due to the 
statement on author's website: 
http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt

However, the file is distributed along with an Unicode fonts set, and 
here's what author has to say about it:

 > The copyright status of these fonts remains the same as for the 
original fonts in the X11 distribution

http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html

And the fonts are under public domain (copyright information is 
available in each individual .bdf file). As per ASF guidelines, public 
domain is handled by adding an attribution line to NOTICE. Don't really 
know why I haven't done it back then.

Re: How do we handle an Incubator release

Posted by Dave Brondsema <da...@brondsema.net>.
To help us move along towards the release, I ran the Release Audit Tool again
and fixed up some missing headers and added .  They were pretty trivial changes
so I did them on master, they can be reviewed here in case I did anything wrong:

https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab

https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898

After that, I was left with just one file without license info:
Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
It looks like it was sourced from somewhere else and I couldn't find a license
for it.  But it's just test data, so maybe it doesn't need a license, or maybe
we can remove the test that uses it.  Thoughts?

On 5/8/13 1:41 PM, Peter Hartmann wrote:
> W dniu 08.05.2013 16:58, Dave Brondsema pisze:
>> I wonder if maybe we should do a simple first release (e.g. tarball of the whole
>> thing, if that's the easiest option).  Then we could get our first release out
>> sooner.  We can also work through any licensing/procedure concerns on the first
>> release(s) and not have to worry about technical complexities at the same time.
> I sort of agree. Also, I was going to mention that later, but it seems to me now
> that "codebase tarball" would be better way to do things because as far as i
> know, tests are typically omitted from pypi packages.Tim was right again :)
> 
> One problem I can see is that Allura doesn't seem too portable. I fixed some
> related errors occuring on my distro (Arch Linux) but this may only be tip of an
> iceberg.Well, it's not like we'll know unless we get more people using it :P
> 
> If it is possible, i'd recommend to mark this release as alpha or beta. As a
> user I'd be surprised to find that stable release only works on a specified
> setup of Ubuntu.
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: How do we handle an Incubator release

Posted by Peter Hartmann <ma...@gmail.com>.
W dniu 08.05.2013 16:58, Dave Brondsema pisze:
> I wonder if maybe we should do a simple first release (e.g. tarball of the whole
> thing, if that's the easiest option).  Then we could get our first release out
> sooner.  We can also work through any licensing/procedure concerns on the first
> release(s) and not have to worry about technical complexities at the same time.
I sort of agree. Also, I was going to mention that later, but it seems 
to me now that "codebase tarball" would be better way to do things 
because as far as i know, tests are typically omitted from pypi 
packages.Tim was right again :)

One problem I can see is that Allura doesn't seem too portable. I fixed 
some related errors occuring on my distro (Arch Linux) but this may only 
be tip of an iceberg.Well, it's not like we'll know unless we get more 
people using it :P

If it is possible, i'd recommend to mark this release as alpha or beta. 
As a user I'd be surprised to find that stable release only works on a 
specified setup of Ubuntu.