On 2015-12-24, 08:44 GMT, Peter von Kaehne wrote:
> The following is an adaption for the new more or less
> automatic process
> which I now use for publication of modules on the CrossWire site.
So, I wonder whether somebody finally pushes to the repository
my update of CzeBKR with conf file on
Will do. Probably tonight
On Sun, 2015-12-27 at 11:43 +0100, Matěj Cepl wrote:
> On 2015-12-24, 08:44 GMT, Peter von Kaehne wrote:
> > The following is an adaption for the new more or less
> > automatic process
> > which I now use for publication of modules on the CrossWire site.
>
> So, I
If CrossWire is eligible for the same type of free license on Stash and
Bamboo that we receive for JIRA, I can help automate this process into
requiring only a commit to a Stash repository which automatically initiates
the build and deploy of modules.
Some nice integration points exist between
As regards details, I've replied in an email direct to you.
I didn't include any crap in the conf files.
It conforms to what is described in the wiki page.
Module makers should want to first satisfy themselves that the module works
properly.
That's why I included all the relevant lines in the
Which parts are required and which are not should be documented in the wiki
page.
I still don't really understand why this has to be done.
It's a huge change from how modules have always been submitted.
If I find it confusing, I'm sure others with less experience will.
David
--
View this
On Sat, 2015-12-26 at 08:20 -0800, David Haslam wrote:
> Module makers should want to first satisfy themselves that the module
> works
> properly.
> That's why I included all the relevant lines in the conf.
There is nothing stopping you from creating your own conf file. This
does not release you
On Sat, 2015-12-26 at 09:24 -0800, David Haslam wrote:
> If I find it confusing, I'm sure others with less experience will.
It is not because I am able to tell simply send me a long and a short
spiel about your module and advise me of the copyright situation. Which
reflects the three minimum
Wow. A little grace would go a long way
in this thread.
I don't regard the idea of automatic conf file generation as
fundamentally flawed. I recommend it, as long as it is done well.
I do it all the time. I just start with a more complete set of
IMHO: The approach is not *fundamentally* flawed. Perhaps it should be advisory
at this time. But there are certainly some elements that are purely mechanical
and these can be automated. And should be.
Cent from my fone so theer mite be tipos. ;)
> On Dec 26, 2015, at 6:45 AM, David Haslam
I understand the motivation behind it, which is to save time,
by having a repeatable method that can be launched by a single click (as it
were).
But it's not saving time overall because it's being done so badly.
It's wasting time for those of us who submitted good working modules!
This causes a
On Sat, 2015-12-26 at 07:16 -0800, David Haslam wrote:
>
> But it's not saving time overall because it's being done so badly.
>
Well it has saved my time - apart from answering your emails I have
even cumulatively spend less time on this than on any publication
prior, including republication
Recent experience of how badly this works in practice has led me to the
conclusion that the approach is fundamentally flawed.
When an experienced module developer submits a module for release, it is
unacceptable for his work to be altered by scripted changes to the conf
file.
This reflects badly
Michael writes, "Wow. A little grace would go a long way in this thread."
Admittedly, I've expressed some things rather strongly.
That's simply because until earlier this evening, I was the only one seeing
the issue.
The script-generated conf files I installed from the repo contained lines
that
I love good bug reports. They help fix issues. Details & how and why something
is wrong will lead to correct fixes. (Well, mostly! It relies on having free
time to implement the fixes, hey!)
I love the idea of all of this being automated, but it relies on more work
initially to refine to tools
Dear All,
The following is an adaption for the new more or less automatic process
which I now use for publication of modules on the CrossWire site.
Please ensure that all OSIS files you submit have the correct
osisIDWork, osisWork and xml:lang entries in the OSIS header. This is
important.
15 matches
Mail list logo
