Oh yeah, I agree with that.
Matthias Wessendorf wrote:
On Thu, Apr 17, 2008 at 6:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
Jira is nice if you want some comments to be kept with the bug. This is
useful for commenting on tickets that do not have patches (and may not for
some time) so that when people finally do get around to it, they have the
information they need.
It is also good for documenting WHY something was done or maybe a synopsis
of the discussion (like a link or something), but the mailing lists are
absolutely the right place to do it.
I meant for not the correct place for API discussion :)
I haven't said that JIRA is bad. Actually, I like it.
I am happy to have to deal with bugzilla on a day-base ...
(bad me, since bugzilla is true OS software)
-M
Scott
Matthias Wessendorf wrote:
MyFaces Core and the Portlet Bridge have an API policy in that the API
is
dictated by a Portlet Bridge spec. They don't have any guidelines in
IMPL
yeah, spec impls (at least their APIs don't count).
It's time for a new lifecycle phase... :D
though. I think the majority of the projects rely on the committeers to
review and test any additions.
yeah, less or more. Maven is pretty picky, so is Lucene.
But at the old job, we never had issues with incompatibility with
Lucene updates.
But like Matthias said, it's a good idea to bring it up in an email.
Stuff
tends to be better when the community is involved.
yeah, jira is a bad discussion platform (at least for me)
-Matthias
Scott
Matthias Wessendorf wrote:
Hi,
On Thu, Apr 17, 2008 at 5:47 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> I would like to have:
>
> 1) Major and Major.Minor support
> 2) A syntax that is already supported by CSS @ styles in at
least
one
> browser or as close as we can come
> 3) Range, greater than and less than if possible
These all sound good to me. The underlying style handling layer
(the
old XSS stuff) was never designed to support #1 or #3, but think it
would be worthwhile to see what we can do to address these.
>
> #2 I think is really important so that skinning feels familiar
to
CSS
> developers.
>
> If the solution meets those needs, I will be very happy, but
others
> can decide on the exact syntax, I'm flexible
I've got a process question here, which I am a bit hesitant to ask
given our recent "discussions", but, well, what the heck...
Shouldn't
we be discussing/reviewing such requirements/API additions before
the
changes are committed to the trunks? Not that I am not grateful
that
at least (I personally think) having a "I am about to commit this" is
not
a
bad thing (tm)
Cristi has invested the time on providing a solution (thanks for
doing
this Cristi!). I am just wondering whether in general it would be
better to review/agree on new APIs before they get committed.
Does Trinidad (or MyFaces) have any policy/guidelines on how new
API/feature additions should be handled? Not picking on Cristi
here -
Nope. Not that I know. Some other Apache projects have; some not.
I think that for adding new APIs, we might want that we at least get
an alert before :-)
I recently added some new skinning features myself and wasn't sure
whether there were some specific steps that I needed to follow.
haven't you ping the mailing list? If not, go ahead !
If it is just still in jira, well... it can be
there for a while. Bug trackers aren't that cool for discussions.
Mailing
list are (I hate forums)
-M
Andy
