Hi,
So as I understand it, if we want to continue to use the old "source" job we
will have to edit our config.json to add "source-each" to the exports and
change any scripts or code that run generate.py to now call "source-each"?
And trying to use the the "source-hybrid" job will cause an error?
For my two cents, I think it's debatable which would be the more natural for
a newbie but for existing developers changing the names of the jobs is
annoying because it was not necessary and it requires existing developers to
edit their config.json to maintain the same functionality (in my case there
is code outside Qooxdoo to change too). It's great that you're highlighting
the change in a blog post, but if someone does not happen to read that blog
post or accidentally tries to use an out of date config.json or a script,
the generator will not work as expected. It won't give an error or a
warning it will just silently produce different code. If the user or
script tries to use "source-hybrid" it will not be able to complete.
IMHO the better solution would be to use the already available default-job
to set the default to "source-hybrid" and change the getting started
documentation to tell users to just "./generate.py" -- existing developers
probably already know about source-hybrid and are making an explicit choice,
newbies can find out about full source builds later, and nothing is silently
broken.
John
From: Derrell Lipman <derrell.lip...@unwireduniverse.com>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Mon, 26 Sep 2011 21:14:07 -0400
To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] Poll: Generator "source" jobs (promotion of
"source-hybrid" to "source")
On Mon, Sep 26, 2011 at 18:58, thron7 <thomas.herchenroe...@1und1.de> wrote:
>> > I had two problems with this change. Firstly, it was initially "announced"
>> > only in the commit message that changed it. The real announcement came
>> > months later. The problem this produced was that although I'd seen the
>> > commit message, I couldn't remember the name "source-each" and it was
>> > difficult to track it down to figure out what command to use for the "old"
>> > behavior.
>
> Derrell, I really don't know what you are talking about. The commit that
> changed the 'source' job and added 'source-each' was on Aug 19 [1], and on
> the exact same day this change was announced in the weekly [2], among
> other things naming 'source-each'.
My mistake. I didn't recall seeing that weekly; I recalled Martin's
re-opening of the bug report when he returned from vacation, saying that we
should revisit it. (And it "feels" like it was a lot longer ago that Aug 19.
:-) )
>
>> > Typing "generate.py --help" to get a list of jobs didn't list
>> > it,
>
> You knew before that --help doesn't give you the job list, didn't you?!
There is _something_ that one can do to get a list of the jobs. I know that,
because I got it. I don't recall what I did, though.
>> > The second big issue I had was that "generate.py source-each" wouldn't
>> > work
>> > because my config.json didn't know about it. I had to manually add
>> > "source-each" to the export list before it could be used.
>
> Yeah, that's a good one. I forgot to mention this in the blog post, and I
> would have loved to see a bug for it opened.
I've been awaiting the resolution of the bug that got re-opened. If this was
going to remain, I would have mentioned that this need should be documented.
>> > This is a
>> > sufficiently "advanced" feature that I don't feel it's appropriate to put
>> > people through it.
>
> Derrell, you must be kidding. It will work out of the box for new
> projects, and for existing projects to add a few entries in the "export"
> section is a no-brainer if you're instructed to do so.
Yes, I know you believe that. You and I have had this discussion before.
You've built a technically fabulous solution, and you're proud of it. I
understand that. I believe, however, that the build system should be easy
enough for beginners to understand, even at the expense of nice features of
the current system. I do not believe that users should have to add some
command that they don't even understand to a configuration file that they
don't understand, in order to keep an existing application work. If it can
be done by the migration script, I think it's fine. If it can't be done by
the migration script, then I think it warrants discussion as to whether it
is an appropriate change.
(My post was, after all, a response to query for opinions, so I felt free to
express mine. :-) )
> For people working on trunk it should go without saying that they may bump
> into such issues, which are easily resolved with a post on the mailing
> list. (Of course I also expect those guys to regularly read the
> weeklies...).
Yup. I work with trunk, and I watch bugs, commit messages, and the weeklies.
Most of the time, I even remember what I read. :-) I also was able to solve
my own problem. My comments are not pertaining to us trunkies, but rather to
the unsuspecting less knowledgeable user who has to make obtuse changes for
no clear benefit.
Cheers,
Derrell
----------------------------------------------------------------------------
-- All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1_________________________________________
______ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
