> s/could/absolutely will/. It's a remarkably strong incentive not to
> submit project proposals for 4.2.
Sadly, that's true, if people want to game the system.
Whether or not people do it, the *incentive* still exists and I worry a bit
about creating an incentive to "game the system", as you put it. A more
serious concern is that some projects do come up at the spur of the moment
and this systems gives those effective priority over planned projects and
that seems backwards.
If we think that's a big enough problem, we should just back away from
this whole idea of me trying to do any scheduling. I can't see how to
do it, if we don't trust the majority of the players. I guess I'm a
little more trusting than you, and think that the GCC community is
pretty good at building up a self-regulating culture, once there's
sufficient buy-in for an idea.
My concern is schedules, as was stated before by somebody else (sorry, but I
forgot who). Basically, what you're trying to do is somewhat akin to ATC's
job in keeping a constant flow of arrivals into a busy airport. But that
only works if the ETA of each aircraft is known to approriate precision.
Here, it's not a matter of "trust", but that software projects, especially
those done by volunteers, tend to not go according to schedule a lot of the
time. As slips occur, the ordering will have to be constantly updated and
it's not clear that such a dynamic list is worth maintaining.
My suggestion is to view you as maintaining a list of projects ready for
installation but that can't be installed either because the tree is unstable
at the moment or because it's too close to the installation of another
project. If neither of those conditions are true and your heap is empty, any
properly-approved project can be installed. But otherwise, you document the
list and when each project can be installed. As new projects enter the list,
you can reschedule other one behind it if you so choose or delay
installations if it takes longer than expected for the tree to stabilize.
The only major difference between my suggestion and what you're doing
is that I'd include only those projects that are actually ready for
installation in consideration for scheduling.
