[Pharo-project] Not happy with the issues feed from Google
stephane.ducasse at inria.fr
Thu Nov 18 16:58:17 EST 2010
> I'm subscribed to some issues through standard Google Code "star this
> issue" feature. So, I'm aware of the changes happening to these bugs.
> I'm also subscribed to the RSS channel of the Pharo Google Code site,
> but I do not follow it closely so far -- just have not enough time. So
> my point is that interested people still are able to follow the
> bugflow without subscribing the whole list to the updates.
yes but you have to individually register.
> And if you want to make sure people are aware of the work you're
> doing, I'd rather recommend you to pay more attention to the news page
> of the pharo-project.org website.
We cannot do that if this is not automated. Then the news are reviewed by native english speakers.....
Probably we should have a dev news where we could push the issues comments but so far I do not know if this is possible
> And having a list of immediate goals
> and time line for them could also help, I think.
Yes this is why I propose a IRC monthly meeting
> Forcing people to follow all the minor activities happening on the tracker (I mean
> changing milestones, statuses and so on) won't rather help (IMHO).
> I've also created a filter to ignore all such messages after I've seen
> them flooding my inbox. So I even don't see them and this fact somehow
> contradicts to your point of making people aware.
So other people just read them. I have a filter and I read them in batch.
Sometimes just passing 0.5 s on an issue.
> I still think important things are worth talking abouth them. I mean bootstraping
> from kernel or new compiler or something else but in the form of
> goals, plans, progress made and so on. Yeah, I know it's easier to
> speak than actually do :), but effect might be better.
Yes we do not want to replace the communication :)
> You may now ask, why I'm so concerned about this issue, if I do not
> even receive these autogenerated emails :) Ok, I just think that it's
> wrong. But I may be wrong too of course :) There are two things I find
> not practical. One of them is that replying to autogenerated mail in
> the list and not copying these replies to the tracker actually splits
> the discussion and makes it harder for people to track it later.
may be we will need more discipline.
> The other thing is mailing list archives like the one on Nabble. It's just
> becoming harder to surfe them. And I'm not aware of the other
> opensource projects doing the same with their mailing lists.
>> What is the last time you look at the code of the fixes that got integrated? Because if you do not read
>> it how can we do quality control? So if I could I would send the diff of all the package in the mailing-lits as this is done in squeak.
> You can't do quality control this way.
Oh yes believe you do.
I will tell you a small story that explained why I was mad against 3.10 process.
One guy that is in network/web sent a fix and I thought as a 3.9 integrator that I would integrate it.
Then bert reviewed the fix and said that this was bogus so it was not integrated in 3.9.
In 3.10 there was little communication about bugs and I raised this concerned to the squeakfoundation board.
Because if experts do not have access fast to what is happening then they will not look at it then your overall quality will
decrease. This is why I really want the new recentMessage browser because it is gorgeous and I want to use it daily
especially when others are doing integrations ( we want to open the process ).
> Everyone won't look at the code of these fixes, interested people are already looking at them so you
> won't gain anything.
No this is where you are wrong. People are not. I have to add lukas in the bug entry manually ....
I have to ask personnally people to look at specific issue.
> And it's iterative process after all: you make
> changes, people look at the code of these changes doing their job in
> Pharo, and if they're unhappy with these changes you'll know about it
No because when you have time you do not look at other code. You hack your own great stuff.
> But important changes still need to be reviewed by experienced
> community members, no doubts here.
>> Now what we can do to please some of you so far 4, we could create a mailing-list where such mails would be sent.
>> But let us see so far who is really against.
> Don't get me wrong, I'm not extremely against this change. I just
> think that this is not the best way to achieve your goals.
Thanks for sharing that with us.
We will create a separated mailing-list to see how it works.
> My apologies for the long mail.
More information about the Pharo-dev