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
