I'm available to work on River again. Is there something I can do to
contribute to getting the release out, given zero experience with Apache
release process?
Patricia
Dudes,
Can someone please check my URLs in the (unpublished) River site,
because the mirror bits aren't working. I must have done something
wrong, I copied the previous versions but must have messed up
somewhere.
Once they're working then the we can finally announce our release!
Cheers,
Tom
Hi guys,
So including the SPARC issue, are we ready to cut and vote on a new release?
Personally, I think it might be worth starting the vote now anyway.
If people don't want to release because of the SPARC thing or whatever
other reason they can always vote "-1"...
Peter and Sim
http://river.staging.apache.org/building-a-release.html
Gr.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
ff some because Peter is going to
add some more things in and then I'll have to cut a new release.
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 14 Jun 2011 21:40, "Patricia Shanahan" wrote:
> I'm available to work on River
27;s always good to get others to check.
having said that, you might want to hold off some because Peter is going to
add some more things in and then I'll have to cut a new release.
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 14 Jun 2011 21:40
acts and check that the sources
>> build, that the bin and doc versions contain what we expect them to,
verify
>> the hashes etc.
>>
>> I think thatthey're fine, but it's always good to get others to check.
>>
>> having said that, you might want to hold of
With recent issues I've marked as resolved in Jira, I was unable to
assign the affected release version, the field doesn't take input in my
browser.
In the previous release of Jira, I was able to set the River release
version for issues, this is of course very useful for the
auto-
I'll try and get that done tonight as well.
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 16 Jun 2011 09:32, "Peter Firmstone" wrote:
> With recent issues I've marked as resolved in Jira, I was unable to
> assign the aff
verify
the hashes etc.
I think thatthey're fine, but it's always good to get others to check.
having said that, you might want to hold off some because Peter is going
to
add some more things in and then I'll have to cut a new release.
Grammar and spelli
I've started taking a look at the release notes, and found a couple of
broken links, to incubator and jini.net, in the html files.
I have other commitments tomorrow, so I probably won't be able to do
much about this until Sunday.
Will jini.net be alive again, at least as
Patricia Shanahan wrote:
I've started taking a look at the release notes, and found a couple of
broken links, to incubator and jini.net, in the html files.
I have other commitments tomorrow, so I probably won't be able to do
much about this until Sunday.
Will jini.net be alive
Hi guys,
Has anyone managed to take a look at the latest release artifacts? If
you're able to, can you let me have your comments, please? I'm really
eager to get this release out the door.
I'll start a(nother) vote thread (or someone else can!) tomorrow if no comments.
Cheers,
Tom
I'm not going to be able to finish my stuff and test it well enough to
get it into the next release.
Peter; are you happy with your commits and merging? Are we ready to
start cutting a new release yet?
Does anyone else have any additional code etc they want rolled into
the next release?
C
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
Cheers,
Tom
Hi,
Was wondering how we are doing with getting the next release out the door? I'd
like to suggest that we move on this as soon as possible If there are issues
that do come up with the release, we can always release again.
Regards
Dennis
Hi,
I didn’t want to add this to the thread that Patricia started, but IMO I’d like
us to push for a new release ASAP. Peter’s done a ton of work, there are
improvements needed to the RMI classloading approach that can help projects out
there today that use OSGi, and we have to do something
Would it be useful to tag it as a 3.0 beta release initially, or just go
to 3.0 and add point releases as needed?
I will vote in favor of releasing it either way.
On 8/6/2015 9:55 AM, Bryan Thompson wrote:
Or just release it. If problems emerge, people can report them and they
can get fixed
Getting another set of release artifacts 4 River3 ready and have run all tests
again, need to generate pgp signatures on weekend.
Decided not to use X500 release cert to sign jar files this release to prevent
holding up progress, since I haven't worked out how others can verify re
I've reviewed the proposed patch for
https://issues.apache.org/jira/browse/RIVER-395, and I think it should
be incorporated in the release. I'm working on a QA test for it, but
could check it in untested if you like.
Patricia
On 4/10/2011 1:09 PM, Tom Hobbs wrote:
Hi guys,
So
No, that's great. Let's wait on your test for that and then put it to
the vote.
Is anyone else working on anything specific for this release?
On Sun, Apr 10, 2011 at 9:23 PM, Patricia Shanahan wrote:
> I've reviewed the proposed patch for
> https://issues.apache.org/jira/
Sorry mate, didn't realise they were up again will look at them today.
Cheers,
Peter.
- Original message -
> Hi guys,
>
> Has anyone managed to take a look at the latest release artifacts? If
> you're able to, can you let me have your comments, please? I'm
I downloaded the source, and tried a naive build on Windows XP, Cygwin.
I put a JDK 1.5 bin directory at the start of my path, and ran "ant
all.build". It failed with the following errors:
compile:
[javac] Compiling 1993 source files to C:\Documents and
Settings\Administrator\My
Documents
they were up again will look at them today.
>
> Cheers,
>
> Peter.
>
> - Original message -
>> Hi guys,
>>
>> Has anyone managed to take a look at the latest release artifacts? If
>> you're able to, can you let me have your comments, please
27 Jun 2011 23:25, "Peter" wrote:
> > Sorry mate, didn't realise they were up again will look at them today.
> >
> > Cheers,
> >
> > Peter.
> >
> > - Original message -
> > > Hi guys,
> > >
> > > Has anyo
Tom Hobbs wrote:
I'm not going to be able to finish my stuff and test it well enough to
get it into the next release.
Peter; are you happy with your commits and merging?
Almost, I've got to remove some things that are preventing compillation on Java 7.
Are we ready to
start cut
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
none. go for it!
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Qu
On 28-10-12 15:45, Simon IJskes - QCG wrote:
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
none. go for it!
Although, what do we do
What's the current status on trunk is there much work left to do for
release?
Run rat and publish the artifacts?
I'd like to see a release out the door prior to refactoring the qa
suite, the refactoring will take some time.
Regards,
Peter.
Agreed, particularly if the JDK 7 issue has been resolved, it'd be good to
get a release out there.
On Thu, Mar 28, 2013 at 7:14 PM, Dennis Reedy wrote:
> Hi,
>
> Was wondering how we are doing with getting the next release out the door?
> I'd like to suggest that we m
Dennis Reedy wrote:
Hi,
Was wondering how we are doing with getting the next release out the door? I'd
like to suggest that we move on this as soon as possible If there are issues
that do come up with the release, we can always release again.
Regards
Dennis
We can safely ignor
On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
> Dennis Reedy wrote:
>> Hi,
>>
>> Was wondering how we are doing with getting the next release out the door?
>> I'd like to suggest that we move on this as soon as possible If there are
>> issues th
skunk/qa-refactoring? I've included the logging
fix.
Regards,
Peter.
- Original message -
>
> On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
>
> > Dennis Reedy wrote:
> > > Hi,
> > >
> > > Was wondering how we are doing with getting the
On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
Dennis Reedy wrote:
Hi,
Was wondering how we are doing with getting the next release out the door?
I'd like to suggest that we move on this as soon as possible If there are
issues that do come up with the release, we can alway
Peter:
I've run the test suite on MacOSX, and got the failure on the
ExpirationNotifyTest. Personally, given that the test looks pretty
contrived, I wouldn't hold up the release basedn on this failure.
Nonetheless, later tonight I'll try to run the test again with some more
d
est suite on MacOSX, and got the failure on the
> ExpirationNotifyTest. Personally, given that the test looks pretty
> contrived, I wouldn't hold up the release basedn on this failure.
> Nonetheless, later tonight I'll try to run the test again with some more
> debug loggin
Thanks for that, appreciate it.
Couple of questions to clarify...
On 1 April 2013 12:13, Peter Firmstone wrote:
> Shown below is both a passing test result and a failing one, logging =
> FINEST.
>
> Lease.FOREVER is actually set to 60,000.
>
>
I take it you mean that the test's own notion of f
Dan Creswell wrote:
Thanks for that, appreciate it.
Couple of questions to clarify...
On 1 April 2013 12:13, Peter Firmstone wrote:
Shown below is both a passing test result and a failing one, logging =
FINEST.
Lease.FOREVER is actually set to 60,000.
I take it you mean that the
gt;>> isn't present in the queue; that could explain some issues.
>>>
>>> I much prefer idempotent code myself.
>>>
>>> This could take some effort to fix, any volunteers?
>>>
>>> Dennis are you able to continue with your 2.2.1 branch r
Hi Dennis:
I think the suggestion was that we do a release branched off the 2.2.0
release with a bare set of patches moved over - primarily the Logging
fix and I think there was a change to one of the JRMP context classes
that I needed for the Surrogate container. And then a release from the
On Apr 3, 2013, at 1030AM, Greg Trasuk wrote:
> Hi Dennis:
>
> I think the suggestion was that we do a release branched off the 2.2.0
> release with a bare set of patches moved over - primarily the Logging
> fix and I think there was a change to one of the JRMP context classes
wrote:
>
> > Hi Dennis:
> >
> > I think the suggestion was that we do a release branched off the 2.2.0
> > release with a bare set of patches moved over - primarily the Logging
> > fix and I think there was a change to one of the JRMP context classes
> > that I ne
any case, I think your suggestion works,
> barring any other opinions.
I was going to update the Levels code in the branch. Once we get that branch up
to snuff and ready to release I think we tag it 2.2.1
Regards
Dennis
icy")
>
Ahh... That makes sense.
> > I recall we decided not to
> > do too much in the trunk. In any case, I think your suggestion works,
> > barring any other opinions.
>
> I was going to update the Levels code in the branch. Once we get that branch
> up to snu
.
>>
>> I was going to update the Levels code in the branch. Once we get that branch
>> up to snuff and ready to release I think we tag it 2.2.1
>>
> OK, go ahead and update the Levels code. I'll run a diff and see if
> there's anything else that should be ported now.
Ok, all set. I also pushed roll_release.sh and common.xml (updated version to
2.2.1)
Dennis
the queue; that could explain some issues.
> > > >
> > > > I much prefer idempotent code myself.
> > > >
> > > > This could take some effort to fix, any volunteers?
> > > >
> > > > Dennis are you able to continue with your 2.2
xplain why as performance improves more issues
> arise.
> > > > >
> > > > > If a task completes before another task which it's supposed to
> runAfter
> > > > > but isn't present in the queue; that could explain some issues.
> > > &g
7;s quite possible that TaskManager is
> causing issues
> > > > > and it might also explain why as performance improves more issues
> arise.
> > > > >
> > > > > If a task completes before another task which it's supposed to
> runAfter
&
g 2.2.1 from the 2.2 branch. Once everything
passes muster (Greg is running tests) we will tag the branch 2.2.1 and release.
>
> i.e. We shouldn't just pick a branch we have, we should get one sorted and
> right now.
>
> What are our chances of pulling just qa changes out of qa
ses from. So we need a branch that is.
>
> AFAIK we are going to be releasing 2.2.1 from the 2.2 branch. Once
> everything passes muster (Greg is running tests) we will tag the branch
> 2.2.1 and release.
>
> >
> > i.e. We shouldn't just pick a branch we have, we sh
Just to clarify:
Dennis & Greg are using the 2.2.0 branch from last release to fix Levels
and release 2.2.1
trunk started failing tests after some unrelated changes exposed
synchronization errors in the qa tests, since then
skunk/qa-refactoring is being used to fix synchronization is
The "2.2" branch is very clean. It starts from release in 2011. Since
then, Dennis applied RIVER-417, added poms for listing at Maven Central,
and applied the Levels fix. I've applied RIVER-149, and that's it.
A few days ago, I set out to see what else from the trunk shoul
t's
possible to do a bunch of commits on master, but it's not the usual
practice.)
-j
On Sat, Apr 6, 2013 at 7:25 PM, Greg Trasuk wrote:
>
>
> The "2.2" branch is very clean. It starts from release in 2011. Since
> then, Dennis applied RIVER-417, added poms
The "situation" would still have occurred, the release process was
delayed by synchronization bugs, without which the release would have
been much simpler with fewer changes. Of course the code is actually
much better now, so it's not a bad situation, we just need to make sure
ssible to do a bunch of commits on master, but it's not the usual
> practice.)
>
> -j
>
>
> On Sat, Apr 6, 2013 at 7:25 PM, Greg Trasuk
> wrote:
>
> >
> >
> > The "2.2" branch is very clean. It starts from release in 2011. Since
> >
>
> -j
>
>
> On Sat, Apr 6, 2013 at 7:25 PM, Greg Trasuk wrote:
>
> >
> >
> > The "2.2" branch is very clean. It starts from release in 2011. Since
> > then, Dennis applied RIVER-417, added poms for listing at Maven Central,
> > and app
The "2.2" branch is very clean. It starts from release in 2011. Since then,
Dennis applied RIVER-417, added poms for listing at Maven Central, and applied
the Levels fix. I've applied RIVER-149, and that's it.
A few days ago, I set out to see what else from the trunk shou
On 4/7/13 4:25 AM, Greg Trasuk wrote:
The "2.2" branch is very clean. It starts from release in 2011. Since
then, Dennis applied RIVER-417, added poms for listing at Maven Central,
and applied the Levels fix. I've applied RIVER-149, and that's it.
Probably to Dennis.
On Apr 8, 2013, at 913AM, Mark Brouwer wrote:
> On 4/7/13 4:25 AM, Greg Trasuk wrote:
>>
>>
>> The "2.2" branch is very clean. It starts from release in 2011. Since
>> then, Dennis applied RIVER-417, added poms for listing at Maven Central,
>> and
Hi all:
I've been testing the 2.2 branch locally in a few environments, and I
haven't seen anything that looks like anything but local configuration
issues. So I'd like to move forward with the release process (steps
will be described below). I have few questions first...
Leve
instance of my own to run test builds in the future. Perhaps others
should think of doing the same thing). In any case, given the minimal
changes from 2.2, I'm now comfortable going forward with a release.
I'm currently building the 2.2.1 release candidate and am thinking of
calling for
On 30/04/2015 17:13, Dennis Reedy wrote:
> Hi,
>
> I didn’t want to add this to the thread that Patricia started, but IMO I’d
> like us to push for a new release ASAP. Peter’s done a ton of work, there are
> improvements needed to the RMI classloading approach that can help projec
Sounds good. Does Apache do release candidates as well? If not,
let's make sure that the existing deployed footprint (which is large)
has a chance to evaluate the branch before the 3.0 release.
Bryan
On Thu, Apr 30, 2015 at 11:13 AM, Dennis Reedy wrote:
> Hi,
>
> I didn’t want
Java 8. I’m planning to apply that patch soon and spin a release of
2.2.x as well.
Cheers,
Greg Trasuk
On Apr 30, 2015, at 11:23 AM, Dawid Loubser wrote:
> I strongly support this! Peter's work needs to get out there and be
> battle-proven, and anything that even inches towards
sn’t compile with Java 8. I suppose
> if a given user’s build system uses classdep, then it would be a problem as
> well. Do people often use classdep? I never have.
>
> Having said that, there was a patch contributed to make the build system work
> under Java 8. I’m planning
I would have sworn that we had consensus six months ago to merge Peter’s work
from the qa_refactor branch back onto the trunk. Peter needs to declare it
“done”, and other people need to look at it, then someone needs to release it.
Unfortunately I don’t have the spare cycles to act as release
Apache is kind of like Yoda - release or do not, there is no candidate. ;- )
“Release” is more of a licensing thing.. We’re putting out the Foundation’s
assurance that the code is Apache-licensed and of known provenance. River is
perfectly free to put out a release where we can’t swear to
I can free up some cycles. Unfortunately, the last time I was closely
involved in a software release was over 30 years ago - I switched to
system performance and hardware architecture. Even then, I was the
compiler project leader, not the release coordinator.
On the other hand, I can free up
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, "Patricia Shanahan" wrote:
> Would it be useful to tag it as a 3.0 beta release initially, or just go
> to 3.0 and add point releases as needed?
>
> I will vote in favor of releasing i
Is there anything that needs to be done before calling for a PMC vote on
the release?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, "Patricia Shanahan" wrote:
Would it be useful to tag it as
them.
Cheers,
Greg Trasuk
> On Aug 7, 2015, at 2:54 AM, Patricia Shanahan wrote:
>
> Is there anything that needs to be done before calling for a PMC vote on the
> release?
>
> On 8/6/2015 11:56 AM, Bryan Thompson wrote:
>> Just release to encourage people to use it. +1
Ivy to get the dependencies at
> runtime, or setup and document a separate download process for them.
>
> Cheers,
>
> Greg Trasuk
>
>> On Aug 7, 2015, at 2:54 AM, Patricia Shanahan wrote:
>>
>> Is there anything that needs to be done before calling for
t be
needed now. Of the other ones, I suspect that the
‘reggie-nameservice-provider’ could be generated. Most of the others are older
versions of packages that are available from Maven Central. Only
‘animal-sniffer’ and ‘asm 3.2’ are present in the river-2.2.2 release and I
don’t think anima
Bryan,
Are you able and willing to act as release manager for 3.0?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, "Patricia Shanahan" wrote:
Would it be useful to tag it as a 3.0 beta release
Apache project release. I am just not a good candidate for this.
Thanks,
Bryan
On Saturday, August 8, 2015, Patricia Shanahan wrote:
> Bryan,
>
> Are you able and willing to act as release manager for 3.0?
>
> On 8/6/2015 11:56 AM, Bryan Thompson wrote:
>
>> Just releas
Peter? Anyone?
I have time, but not the knowledge. I would be willing to be release
manager provided at least one person who knows how it is done will
provide a lot of step-by-step guidance.
On 8/8/2015 7:21 AM, Bryan Thompson wrote:
Not really I am afraid. I am quite heavily committed on
I am going to include the lack of a release manager for 3.0 in the board
report, and assign myself an action item to fix it.
At this point I think my best bet is to appeal on the
d...@community.apache.org mailing list for a mentor who is familiar with
the release process to guide me through
Pat:
I can provide support and information for you. But I do think we need to first
sort out the dependencies question I pointed out earlier.
Cheers,
Greg Trasuk
> On Aug 9, 2015, at 9:58 PM, Patricia Shanahan wrote:
>
> I am going to include the lack of a release manager for 3
In that case, I'll take on the actual release manager role, and get
going on dealing with the dependency issue.
On 8/9/2015 8:38 PM, Greg Trasuk wrote:
Pat:
I can provide support and information for you. But I do think we need to first
sort out the dependencies question I pointe
Pat,
I don't have much time, but I'll assist you where I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd
nt.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple library is available on Sourceforge, it's a
Collection
Excellent. I am glad to see this moving forward.
Copying Brad, who heads our CI integration efforts. We have a large
refactor coming back to master on our code base, once that is stable we can
look at a refactor to the new river release package names and provide
feedback based on that.
Please
,
I don't have much time, but I'll assist you where I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant re
ere I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-appl
> On Aug 10, 2015, at 7:53 AM, Peter wrote:
(…snip…)
> CombinerSecurityManager avoids duplicated security checks (from identical
> context) by weakly caching (by caller context's) the result of security
> checks, this reduces unnecessary network traffic caused by duplicated
> security check
It looks as though I should be pursuing two sub-projects in parallel:
1. Get a Linux machine set up.
2. Analyze the libraries to make sure everything is needed. I am less
concerned about libraries that are only used in the QA tests.
On 8/10/2015 6:30 AM, Greg Trasuk wrote:
On Aug 10, 2015,
Hint: have a look at DNS calls caused by CodeSource.implies and
SocketPermission. There may be multiple network calls for each
permission check.
The new policy providers work around these issues where they can.
Regards,
Peter.
On 10/08/2015 11:30 PM, Greg Trasuk wrote:
On Aug 10, 2015, at
You guys rock - thanks for all the effort involved.
Dawid Loubser
On 02/09/2015 15:01, Peter wrote:
> Thanks Dennis.
>
> On 2/09/2015 10:58 PM, Dennis Reedy wrote:
>> Peter,
>>
>> Should be all set now, just pushed the missing sources and resources.
>>
>> Dennis
>>
>>> On Sep 2, 2015, at 357AM,
If you have it handy :)
On 3/09/2015 12:43 AM, Dennis Reedy wrote:
Sooo … do you need the package rename utility?
Dennis
Initial jtreg regression test results, will look into it later:
Sorry we don't have the Bug ID's from the Sun bug database, Sun / Oracle
never donated them.
java/rmi/server/RMIClassLoader/loadProxyClasses/PreferredLoadProxyClasses.java
Failed. Execution failed: `main'
But as I said,
I don’t have a strong opinion.
I do have a strong opinion about the use of dep-libs. I don’t like it. I
don’t like it at all. We need to deal with getting jar files out of the source
release. I don’t think we have any business archiving and distributing someone
else’s artifacts
l move it into org.apache.river.config. If thats
the case, then ConfigurationFile should move as well? Otherwise lets keep it in
net.jini.config
>
> I do have a strong opinion about the use of dep-libs. I don’t like it. I
> don’t like it at all. We need to deal with getting jar files
ke it. I
don’t like it at all. We need to deal with getting jar files out of the source
release. I don’t think we have any business archiving and distributing someone
else’s artifacts, even if the license does allow it. I do know that Apache
policy is that releases are source code only. I
point when I suggest that GroovyConfiguration might be best
separated out into a separate project. We could structure a project, discuss
it, vote on a release and have it into Maven Central by the end of next week.
So users of River could have an easy way to use a GroovyConfiguration pretty
muc
+1 on a short path to a 3.0 release. Everything else can go into a
backlog for 3.1+.
Bryan
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://m
ress would lead to paralysis and inevitable obsolesence.
>>
>> The Groovy configuration is far superior to the DSL in many ways,
>
> Please specify.
>
>> leaving it as an implementation detail, discourages usage.
>>
>
> Here is my real point when I suggest that
+1 on getting 3.0 out the door.
I think we should be heading towards a habit of much more frequent
releases. That way, each release will not be as big a deal.
If we can get a quick consensus for a change, we should do it. If not, I
suggest minimum change from what we have now for 3.0. If
ented
>> architectures. We need to consider the users.
>>
>
> And how exactly are we not doing this?
>
>>
>>
>>> locking out progress would lead to paralysis and inevitable obsolesence.
>>>
>>> The Groovy configuration i
I haven’t fully
> explained what I mean by “separate deliverable”. I should probably create a
> separate thread to talk about “projects and deliverables” and how they relate
> to repositories. The gist of what I’m getting at is that a “release”
> shouldn’t be a big thing. Rig
I think that we could:
1. Release 3.0 on the shortest path consistent with appropriate QA.
2a. Refactor the project structure into modules
2b. Extend the project into interesting use case areas (IoT was discussed
recently).
2a and 2b could occur in parallel.
A release with a project modular
1 - 100 of 514 matches
Mail list logo
