On Mon, 13 Aug 2012 17:56:49 -0700, Rob Lanphier <[email protected]>
wrote:
On Mon, Aug 13, 2012 at 11:03 AM, Jeroen De Dauw
<[email protected]> wrote:
Can you be specific and point to these questions we've answered to
vague,
then I'll try to answer then in more detail.
Two places to start off with:
1. In response to Brian Wolff's email. Many interesting questions
were redacted in Denny's response.
2. In response to Tim's July 18 comment here:
https://gerrit.wikimedia.org/r/#/c/14295/
We need generalizations provided by this patch. Yes, that's not
specific at
all to why and where we need them. You'd need to know that to verify
we're
not doing stupid stuff in Wikidata. However, these generalizations make
sense on their own, and can be judged entirely loose from Wikidata.
Not really. Basically, what you're proposing is that these changes are
necessary for Wikidata, that you don't have time to implement the full
solution, and that's why we have to settle for a halfway solution
instead of finishing the job.
I can understand not wanting the scope creep of "finishing the job",
since there's not consensus on what that means. What Daniel suggested
(which seems to also have the support of Chad and Aaron, at least) is
that this is RfC material. If avoiding scope creep is the goal, then
it becomes more important to understand exactly what Wikidata needs
out of this patch, and that involves understanding the parts of
Wikidata that use this.
Educating people on Wikidata internals really seems to be out of scope
to
me.
Given that the Wikidata code needs a full review by many of the same
people that are asking about this particular change, doesn't that seem
largely academic?
How do you figure this? My interpretation from the thread is similar to
that of Denny - we're basically all agreeing that this change improves
on
the current system in various ways, but some thing it should tackle some
issues it's not currently dealing with as well.
My reading is that folks like Daniel and Chad are conceding that the
current system needs to be improved, and that this change *might* be a
step in the right direction, but is probably not far enough to be
worth dealing with the problems of doing this halfway.
Rob
I also feel that some of the changes that don't go far enough or don't
look like the ideal I would have used if I wrote this code, are in areas
such as database schema and potentially overall API. Areas which if this
is committed now will require anyone who tries to finish the project to
add in migrations, etc... just to fix the schema that should have been
done right from the start.
Also there is a key question undecided. Will the sites table be a
first-class edited table. Or act like an index. Not deciding the way we
treat this table right now will make it practically impossible to change
that perception later on, and if we do decide that it should be more of an
index when people have started writing editing interfaces on top of the
table then we would practically have to rewrite it yet again.
Frankly some of the code sets off my rewrite nerves. And if I had the
time/backing I'd collect all the requirements on an RfC page and write the
new system myself.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
