[V3dot10] And to 3.10
milan.zimmermann at sympatico.ca
Mon Jan 22 01:20:13 UTC 2007
On 2007 January 21 10:02, Adrian Lienhard wrote:
> As far as I can remember exactly this was supposed to be the
> responsibility of the teams (http://www.squeak.org/Community/Teams/).
> The whole team model didn't work out as expected in 3.9, although we
> tried to establish a workflow.
> I believe making the process of bug reporting-fixing-integration work
> smoothly should be one of the main concerns. Too often it happened
> that people submit something to Mantis and just never hear back, nor
> their fix gets integrated.
> Marcus put a lot of effort into working through Mantis reports
> although that shouldn't have been his responsibility. I think there
> are just not enough people that really care and have enough time to
> commit to this sort of work.
> I don't have a solution, unfortunately. Motivating people seems hard,
> but will be easier if they see results within reasonable time. Better
> visibility could help too, i.e., it would be interesting to hear from
> the team leaders in their monthly reports which bugs are new, still
> open, have been fixed or require more help from other people.
I think that it is the right thing to make teams responsible for approving
fixes on Mantis for their category of responsibility. (Perhaps with a slight
clarification of how the categories on Mantis map to each team, also
this "mapping" may change once bigger chunks are maintained outside the
image, but it seems the right principle to implement).
The question is how to implement this process. Maybe the release team should
define a time period of say, 2 months (coinciding with the duration of the
first 2/3 of the planned 3.10 alpha period.). During those 2 months, the team
has a chance to approve or reject fixes on Mantis. Fixes that are approved
will be harvested.
What to do at the end of this period if there are categories that were
not "processed" by their teams. Perhaps a 1 month "free approve period" could
follow, allowing anyone to approve fixes, which includes implement and
approve fixes (only those that remained un-approved and un-rejected during
the first 2 months). That way, if anyone has a pressing need for a fix has
a chance to do so (approved fixes must have tests in all situations). This
way anyone has a chance to scratch their itch, even for a fairly low price,
if a fix is already available.
Packages for which teams have no time and noone steps up will remain unfixed.
they may still work and be loadable, if maintained outside, but on their way
Just a thought, not sure how acceptable or useful such process would be.
> Unfortunately, this is pure fantasy...
> > -Ralph Johnson
> > _______________________________________________
> > V3dot10 mailing list
> > V3dot10 at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10