Sorry - I shouldn't have mixed threads in my reply to you.
This covers Cray - what are your thoughts about release cycles, release
criteria, changes to the release process (ciommunity testing), and other
things you initially raised.
Andy
On 04/10/12 21:15, Rob Vesse wrote:
I agree having hard targets can create more problems than it solves for a
open source project though having internal targets may always be useful to
give us something to aim for.
Right now getting a new release is not a priority for Cray/YarcData, we
just shipped a release using 2.7.3 and none of the issues uncovered/fixed
then are in components we use or are serious enough to be an issue for us
right now.
The only thing we will likely want to pick up for the next release is the
changes I've been experimenting with for TSV/CSV boolean results but
that's pretty minor and isn't something that is a problem for any users
right now.
Regardless we'll almost certainly take a new release as soon as it is
available so we can start testing it in our stack and ensure it doesn't
cause us any problems. We primarily only use ARQ/Jena (we dropped Fuseki
a while ago) which hasn't changed that much so we don't anticipate any
problems with adopting the next release
Rob
On 10/4/12 1:04 PM, "Andy Seaborne" <[email protected]> wrote:
On 04/10/12 20:28, Rob Vesse wrote:
Andy
Is it worthwhile for us as a PMC to try to adopt a planned regular
release
cycle?
This could either be dates when we aim to produce a new release e.g. 1st
of the month each quarter or it could just be a general aim of a new
release within N months of the previous release e.g. 3 months after the
previous release.
The latter might be a better option for us as it gives us the
flexibility
to make a new release sooner if there are important changes/fixes we
want
to get out to users but also gives users some guarantee of when to
expect
a new release.
Now there may be times when we can't meet the target because we have
less
time to devote to the project, larger refactors/new features may require
more significant testing and hardening periods etc. but it might be nice
for us to aim to do this.
Yes - a good discussion to have including what the general release
criteria are.
Also, I thought the community testing of SDB went rather well. Calling
a release, getting reports before having to freeze for the vote is a
good thing. We can keep the vote to 3 days. A long vote seems to gain
us little.
In past life the target was once every 6 months but that was for the
more stable bit. As we need to start removing old stuff (e.g. DAML+OIL,
bulk update handlers, ...)
Maybe 3? 4? months?
But it can be too frequent. Many users will not be upgrading each time
(not unreasonably).
It's becoming like Ubuntu LTS and normal releases.
What works for Cray?
We won't always make it - that's for sure. It's a tricky balance to
even mention plans because if you meet the tick point a couple of times
it becomes "expected" :-) Open source projects just seem to have demand
exceeding supply.
I suggested a 2.7.4 release now to sync with SDB ... thoughts? My worry
there was consuming PMC and interested parties bandwidth (I'd have added
LARQ as well as it is incubator'ed but it adds work for us all).
Andy
Rob
On 10/4/12 12:19 PM, "Andy Seaborne" <[email protected]> wrote:
