Defining the damn 3.9 process! (was Re: SqueakFoundation money)

[Adrian Lienhard]

On Dec 9, 2005, at 09:01 , Cees De Groot wrote:

> On 12/9/05, Adrian Lienhard <adi at netstyle.ch> wrote:
>> [...] but not one proposes a concrete solution!
>>
> I thought at least one of my postings had a very concrete solution
> proposal. But it might have gotten lost in the flurry of debate.

I just see your post about grabbing latest packages from the inbox  
and doing an automatic build. I must have missed your concrete  
proposal(?)

>
>> (ii) Assigning issues: After an issue has been reported, there need
>> to be some dispatcher, a responsible person that regularly checks new
>> issues and assigns them to the responsible Steward team.
>
> The Janitors seem to be the team for that (i.c. Ken Causey). And
> they're already doing that.
>
>> [...] (only committing to the inbox does not work!).
>
> Why not?

have a look at the inbox yourself and you will see. The problem is  
missing *visibility* because SqS at this state does not support  
deleting versions from a repository.

Stef reported this on October 1 but his mail was left unanswered. He  
wrote:

"I think that it would be nice to be able to move the inbox mcz  
proposals to
another category such as closed when we took them into account  
(harvested them or not).
How can I create such repo?
Then how can I move (and not only copy) stuff there?"

If we have this feature, of course, the inbox would work very well  
(commiters would have to say which packages belong together, though,  
but that could be done in the comment)!

>
>> I would suggest to maintain a wiki where each team can
>> put items that need to be integrated. This is to keep track of them,
>> in addition, email between the teams should work.
>>
> Why not use Mantis for this? I am not an expert user of Mantis, but a
> good bug/ticketing system should support these kinds of workflows.

yea, I'm not an expert either, but I can't see anything like this.  
The responsible for Mantis might be able to answer? If this is  
possible, even better!
>
>> - since probably several packages are touched, the responsible
>> Stewards teams are informed so that they can review what gets in.
>>
> Hmm... I'm not too happy with that. I think teams should be involved
> in these tasks on a higher level - after all, they'll be responsible
> for the end result, so they should have more of a say than a simple
> yes/no vote.
>
> But then, this is something out-of-the-ordinary anyway, not really
> useful to start a big debate on - the regular bugfixing process is
> what needs to be bugfixed first :)

right, we can still define this when the rest is smoothly working

>
>> On Mantis I really have problems to follow what
>> happens. E.g., I would like to have a RSS feed of any changes (I miss
>> that since they do not appear anymore in the mailing list).
>>
> That's probably a matter of reporting. One issue I raised on the IRC
> channel last night is whether we don't want to run our own Mantis
> instance, so we can hack at will at it. At the moment, it's all a bit

of course, that would be a possibility. Who will do it? Or even, we  
could implement our own bug-tracking system that exactly fits our  
needs...
I think its important to have something up and running _very soon_  
and not try to do a perfect solution because then, all we will have  
in the end are a lot of mails and that's all (sorry to be so  
pessimistic). So, with my proposal I was trying to do TSSTCPW.

> of a black box and if we want to change something, we need to ask
> Impara where every question can get a yes or a no depending on whether
> Impara wants to invest time/effort, whether it doesn't interfere with
> their other products they use Mantis for, etcetera.


Adrian