Mantis usage rules du jour
Locked
12
12
 
|
I'm submitting a bug fix and thought I'd ask what the current favoured procedure is. Simply submitting is as irritating as it ever was in Mantis, but once I've done that, uploaded my fix and made a note about it… what do we do next?
To whom might I assign it for action in getting into the image for the next release? Or is that done some other way now? Is there documentation on the current process that I failed to spot? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: XO: Execute Operator |
Re: Mantis usage rules du jour
|
|
On 22 February 2013 22:27, tim Rowledge <[hidden email]> wrote:
> I'm submitting a bug fix and thought I'd ask what the current favoured procedure is. Simply submitting is as irritating as it ever was in Mantis, but once I've done that, uploaded my fix and made a note about it… what do we do next? > > To whom might I assign it for action in getting into the image for the next release? Or is that done some other way now? Is there documentation on the current process that I failed to spot? Mostly we do the wrong thing, which is commit directly to trunk or, slightly less wrong, commit an mcz to the Inbox (MCHttpRepository location: 'http://source.squeak.org/inbox' user: '' password: ''). So _I_ favour a bug report to Mantis (http://bugs.squeak.org/view.php?id=7740 right?), and if it's small, just commit it to trunk and record that in the tracker. (I find it really, really useful to see the audit trail in Mantis. It might be seriously ugly, but it beats an inbox every day.) Ideally, there's a test accompanying the fix :) but Squeak has some serious legacy stuff, and a test's infeasible. frank |
Re: Mantis usage rules du jour
|
|
On Fri, Feb 22, 2013 at 2:41 PM, Frank Shearar <[hidden email]> wrote:
The Inbox is meant for changes that need review—either contributions from developers without direct access to the trunk, or from core developers that would like a second set of eyes on the code before it goes into trunk. So, sure, a Mantis entry is great, but core developers putting stuff in the Inbox ought to be fairly rare. The idea is to keep it easy to contribute, with minimal ceremony.
Colin |
Re: Mantis usage rules du jour
|
|
Actually Mantis is probably dead. The place to report bugs is presently here. The bug tracker, as far as I can tell, is presently unloved.
On Fri, Feb 22, 2013 at 8:50 PM, Colin Putney <[hidden email]> wrote:
Casey Ransberger |
RE: Mantis usage rules du jour
|
|
Hi all, I hope the reports of Mantis’s demise are premature. There should be a reporting mechanism but I agree it’s difficult if there is no process around the bug tracking or actual owners. We used to have specific owners for portions of the code. Back to Tim’s question, what should the process be? Do we need to have new owners again? Should mantis email squeak-dev? Should mantis email component owners? Do we need new owners? I know that when I first got involved with Squeak, Mantis was the perfect way to get involved. I would place a bug or submit something and Andreas or some other component owner would comment back. There were some really great bug conversations or code contribution ideas that went on in Mantis. I suppose that only works if people that are responsible for portions of the code interact when something is posted. If nobody reads it then it’s just a black hole and can be very frustrating. While conversations about specific topics can happen on Squeak-Dev, it’s just not the same as having the context and decisions documented somewhere specific like Mantis. I may have missed some other comments related to bug reporting so please excuse me if I’m coming to this conversation late. All the best, Ron Teitelbaum From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Ransberger Actually Mantis is probably dead. The place to report bugs is presently here. The bug tracker, as far as I can tell, is presently unloved. On Fri, Feb 22, 2013 at 8:50 PM, Colin Putney <[hidden email]> wrote: On Fri, Feb 22, 2013 at 2:41 PM, Frank Shearar <[hidden email]> wrote:
The Inbox is meant for changes that need review—either contributions from developers without direct access to the trunk, or from core developers that would like a second set of eyes on the code before it goes into trunk. So, sure, a Mantis entry is great, but core developers putting stuff in the Inbox ought to be fairly rare. The idea is to keep it easy to contribute, with minimal ceremony. Colin -- |
|
|
In reply to this post by Colin Putney-3
On 22-02-2013, at 8:50 PM, Colin Putney <[hidden email]> wrote: > > The Inbox is meant for changes that need review—either contributions from developers without direct access to the trunk, or from core developers that would like a second set of eyes on the code before it goes into trunk. I really wish we had enough available eyeballs to review everything. I suggest that the most careful review is required for the sort of changes that 'core developers' produce. If nothing else it is a way to reduce the truck-factor and make sure that things are explained well enough for someone not heavily involved in the original work to be able to understand what is being done. > So, sure, a Mantis entry is great, but core developers putting stuff in the Inbox ought to be fairly rare. The idea is to keep it easy to contribute, with minimal ceremony. No ceremony at all worries me. Call me Captain Slow (cf James May) but I like procedures. They're recipes for maintaining sanity over time. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Is reading in the bathroom considered Multi-Tasking? |
Re: Mantis usage rules du jour
|
|
On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge <[hidden email]> wrote:
Well, it's not quite "no ceremony," we're aiming for "no more ceremony than necessary." Here's the description of the way it's supposed to work now: The development of Squeak 3.11 basically ground to halt because of excessive procedure, and this new model was an attempt to resuscitate it. It worked!
It's possible that we have swung too far in the other direction, but I haven't seen anything that makes me think so. Are there specific problems you want to solve, or is it more of a general unease at the loosey-goosey-free-for-all?
Colin |
|
|
In reply to this post by timrowledge
I would like a bug tool integrated into Squeak and per Monticello package. Could we use Monticello somehow to to report and track bugs ? Karl On Sat, Feb 23, 2013 at 7:12 AM, tim Rowledge <[hidden email]> wrote:
|
Re: Mantis usage rules du jour
|
|
In reply to this post by timrowledge
On 23 February 2013 06:12, tim Rowledge <[hidden email]> wrote:
> > On 22-02-2013, at 8:50 PM, Colin Putney <[hidden email]> wrote: >> >> The Inbox is meant for changes that need review—either contributions from developers without direct access to the trunk, or from core developers that would like a second set of eyes on the code before it goes into trunk. > > I really wish we had enough available eyeballs to review everything. I suggest that the most careful review is required for the sort of changes that 'core developers' produce. If nothing else it is a way to reduce the truck-factor and make sure that things are explained well enough for someone not heavily involved in the original work to be able to understand what is being done. Fortunately, every commit to Trunk results in a diff being posted here, so hopefully people do actually read them and post-fact review them. A few months ago someone did actually have to revert their changes. >> So, sure, a Mantis entry is great, but core developers putting stuff in the Inbox ought to be fairly rare. The idea is to keep it easy to contribute, with minimal ceremony. > > No ceremony at all worries me. Call me Captain Slow (cf James May) but I like procedures. They're recipes for maintaining sanity over time. Given that I'm crotchety, in an ideal world we'd _never_ merge _anything_ without tests covering the proposed change, the tests and feature in a topic branch, and the branch has zero chance of being merged unless the thing you get by merging the topic branch into master passes all tests. Oh, and of course that necessitates a bug report off which to hang the topic branch. (This is actually how most of my work work gets done. It's really, reallly nice for all concerned, and github makes it not even onerous. No, correction. Github makes it _fun_ to review other's code this way.) But we're not in an ideal world. One step at a time. I am a huge fan of bugtrackers and, while Mantis looks like a throwback to the 90s, it works solidly and quietly, and I intend to annoy folks by asking them to post to Mantis! frank > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Is reading in the bathroom considered Multi-Tasking? > > > |
Re: Mantis usage rules du jour
|
|
In reply to this post by Colin Putney-3
On Sat, Feb 23, 2013 at 12:33:14AM -0800, Colin Putney wrote:
> On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge <[hidden email]> wrote: > > > > No ceremony at all worries me. Call me Captain Slow (cf James May) but I > > like procedures. They're recipes for maintaining sanity over time. > > > > Well, it's not quite "no ceremony," we're aiming for "no more ceremony than > necessary." Here's the description of the way it's supposed to work now: > > http://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/ This is really a key point. It did not seem like a big thing at the time, but with the benefit of hindsight I now think of the Andreas' community development model as perhaps his most important contribution to Squeak. I go back and reread his posting from time to time, along with the back to the future paper (http://ftp.squeak.org/docs/OOPSLA.Squeak.html) just to remind myself of the basics. That said, I think that Mantis also plays an important role. Basically it is there for issues that cannot be quickly resolved on the mailing list, or that require some longer term collective memory for the community. I honestly thought our Mantis system had pretty well died off a few years ago, but I kept on using it to record various VMMaker issues that could not be immediately resolved. There are issues like this that for various reasons may require years to bring to conclusion, and it is also helpful to have a record of those issues beyond what is found in email postings and Monticello commit comments. A good example of such an issue that was just recently updated is this one: http://bugs.squeak.org/view.php?id=6828 And an even better example is this one, which was not very important at the time the issue was logged, but which will be very important a few years later as the various VMs move to 64-bit platforms: http://bugs.squeak.org/view.php?id=7237 > > The development of Squeak 3.11 basically ground to halt because of > excessive procedure, and this new model was an attempt to resuscitate it. > It worked! I agree, and I strongly urge a balanced approach. Use Mantis where it makes sense, but don't waste time on procedure for the sake of procedure. Dave > > It's possible that we have swung too far in the other direction, but I > haven't seen anything that makes me think so. Are there specific problems > you want to solve, or is it more of a general unease at the > loosey-goosey-free-for-all? > |
Re: Mantis usage rules du jour
|
|
On 23.02.2013, at 15:14, "David T. Lewis" <[hidden email]> wrote: > On Sat, Feb 23, 2013 at 12:33:14AM -0800, Colin Putney wrote: >> On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge <[hidden email]> wrote: >> >> >>> No ceremony at all worries me. Call me Captain Slow (cf James May) but I >>> like procedures. They're recipes for maintaining sanity over time. >>> >> >> Well, it's not quite "no ceremony," we're aiming for "no more ceremony than >> necessary." Here's the description of the way it's supposed to work now: >> >> http://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/ > > This is really a key point. It did not seem like a big thing at the time, > but with the benefit of hindsight I now think of the Andreas' community > development model as perhaps his most important contribution to Squeak. > I go back and reread his posting from time to time, along with the back > to the future paper (http://ftp.squeak.org/docs/OOPSLA.Squeak.html) just > to remind myself of the basics. +1 > That said, I think that Mantis also plays an important role. Basically it > is there for issues that cannot be quickly resolved on the mailing list, > or that require some longer term collective memory for the community. > > I honestly thought our Mantis system had pretty well died off a few years > ago, but I kept on using it to record various VMMaker issues that could > not be immediately resolved. There are issues like this that for various > reasons may require years to bring to conclusion, and it is also helpful > to have a record of those issues beyond what is found in email postings > and Monticello commit comments. > > A good example of such an issue that was just recently updated is this one: > > http://bugs.squeak.org/view.php?id=6828 > > And an even better example is this one, which was not very important > at the time the issue was logged, but which will be very important > a few years later as the various VMs move to 64-bit platforms: > > http://bugs.squeak.org/view.php?id=7237 Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts? - Bert - |
Re: Mantis usage rules du jour
|
|
On 23 Feb 2013, at 15:47, Bert Freudenberg <[hidden email]> wrote:
> > On 23.02.2013, at 15:14, "David T. Lewis" <[hidden email]> wrote: > >> On Sat, Feb 23, 2013 at 12:33:14AM -0800, Colin Putney wrote: >>> On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge <[hidden email]> wrote: >>> >>> >>>> No ceremony at all worries me. Call me Captain Slow (cf James May) but I >>>> like procedures. They're recipes for maintaining sanity over time. >>>> >>> >>> Well, it's not quite "no ceremony," we're aiming for "no more ceremony than >>> necessary." Here's the description of the way it's supposed to work now: >>> >>> http://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/ >> >> This is really a key point. It did not seem like a big thing at the time, >> but with the benefit of hindsight I now think of the Andreas' community >> development model as perhaps his most important contribution to Squeak. >> I go back and reread his posting from time to time, along with the back >> to the future paper (http://ftp.squeak.org/docs/OOPSLA.Squeak.html) just >> to remind myself of the basics. > > +1 > >> That said, I think that Mantis also plays an important role. Basically it >> is there for issues that cannot be quickly resolved on the mailing list, >> or that require some longer term collective memory for the community. >> >> I honestly thought our Mantis system had pretty well died off a few years >> ago, but I kept on using it to record various VMMaker issues that could >> not be immediately resolved. There are issues like this that for various >> reasons may require years to bring to conclusion, and it is also helpful >> to have a record of those issues beyond what is found in email postings >> and Monticello commit comments. >> >> A good example of such an issue that was just recently updated is this one: >> >> http://bugs.squeak.org/view.php?id=6828 >> >> And an even better example is this one, which was not very important >> at the time the issue was logged, but which will be very important >> a few years later as the various VMs move to 64-bit platforms: >> >> http://bugs.squeak.org/view.php?id=7237 > > > Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts? The reason it doesn't already do this is just that I didn't want to annoy everyone. I think it's a great idea. What granularity ought to apply? Mails on new issues? State changes (to see when something's resolved)? frank > - Bert - > > > |
RE: Mantis usage rules du jour
|
|
In reply to this post by Bert Freudenberg
> From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Bert Freudenberg > Sent: Saturday, February 23, 2013 10:48 AM > > > On 23.02.2013, at 15:14, "David T. Lewis" <[hidden email]> wrote: > > > On Sat, Feb 23, 2013 at 12:33:14AM -0800, Colin Putney wrote: > >> On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge <[hidden email]> wrote: > >> > >> > >>> No ceremony at all worries me. Call me Captain Slow (cf James May) > >>> but I like procedures. They're recipes for maintaining sanity over time. > >>> > >> > >> Well, it's not quite "no ceremony," we're aiming for "no more > >> ceremony than necessary." Here's the description of the way it's supposed to > work now: > >> > >> http://squeakboard.wordpress.com/2009/07/02/a-new-community- > developme > >> nt-model/ > > > > This is really a key point. It did not seem like a big thing at the > > time, but with the benefit of hindsight I now think of the Andreas' > > community development model as perhaps his most important contribution to > Squeak. > > I go back and reread his posting from time to time, along with the > > back to the future paper > > (http://ftp.squeak.org/docs/OOPSLA.Squeak.html) just to remind myself of the > basics. > > +1 > > > That said, I think that Mantis also plays an important role. Basically > > it is there for issues that cannot be quickly resolved on the mailing > > list, or that require some longer term collective memory for the community. > > > > I honestly thought our Mantis system had pretty well died off a few > > years ago, but I kept on using it to record various VMMaker issues > > that could not be immediately resolved. There are issues like this > > that for various reasons may require years to bring to conclusion, and > > it is also helpful to have a record of those issues beyond what is > > found in email postings and Monticello commit comments. > > > > A good example of such an issue that was just recently updated is this one: > > > > http://bugs.squeak.org/view.php?id=6828 > > > > And an even better example is this one, which was not very important > > at the time the issue was logged, but which will be very important a > > few years later as the various VMs move to 64-bit platforms: > > > > http://bugs.squeak.org/view.php?id=7237 > > > Mantis might appear less dead if reports/changes got posted to squeak-dev. > Thoughts? I think it would make sense to send everything but with a [Mantis] tag in the subject, that way someone could easily filter the emails if they wanted to. There were some conversations that I had that would have benefited from being on squeak-dev. We don't want to encourage everyone to join the conversation on mantis, but having side conversations on what is best on squeak-dev would be good. Ron > > - Bert - > > > |
Re: Mantis usage rules du jour
|
|
In reply to this post by Frank Shearar-3
On Sat, Feb 23, 2013 at 04:09:04PM +0000, Frank Shearar wrote:
> On 23 Feb 2013, at 15:47, Bert Freudenberg <[hidden email]> wrote: > > > > Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts? > > The reason it doesn't already do this is just that I didn't want to annoy everyone. I think it's a great idea. What granularity ought to apply? Mails on new issues? State changes (to see when something's resolved)? > I think it's a great idea too. At the current rate of Mantis updates, I would say that all changes on Mantis could be sent to squeak-dev without any problem. Of course that might cause people to start updating Mantis more often, at which point we might want to turn down the noise. One other point to mention - Mantis is for tracking issues, not for debate and discussion. So if a Mantis update appears here on squeak-dev, use the squeak-dev list for discussion of the issue, and update Mantis only when there is new information or status to report. Dave |
Re: Mantis usage rules du jour
|
|
In reply to this post by Ron Teitelbaum
>> Mantis might appear less dead if reports/changes got posted to squeak-dev.
>> Thoughts? > > I think it would make sense to send everything but with a [Mantis] tag in > the subject, that way someone could easily filter the emails if they wanted > to. There were some conversations that I had that would have benefited from > being on squeak-dev. We don't want to encourage everyone to join the > conversation on mantis, but having side conversations on what is best on > squeak-dev would be good. +1 Stef |
Re: Mantis usage rules du jour
|
|
In reply to this post by Frank Shearar-3
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar <[hidden email]> wrote:
Yeah, great idea. I'd say send messages for both, with a [Bugs] tag for easy filtering. Colin |
Re: Mantis usage rules du jour
|
|
On 23.02.2013, at 19:02, Colin Putney <[hidden email]> wrote:
> On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar <[hidden email]> wrote: >> > Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts? >> >> The reason it doesn't already do this is just that I didn't want to annoy everyone. I think it's a great idea. What granularity ought to apply? Mails on new issues? State changes (to see when something's resolved)? >> >> Yeah, great idea. I'd say send messages for both, with a [Bugs] tag for easy filtering. > > Colin +1 for [Bugs] because short. - Bert - |
Let's consider changing how we track issues (was Re: [squeak-dev] Mantis usage rules du jour)
|
|
In reply to this post by Frank Shearar-3
On 02/23/2013 10:09 AM, Frank Shearar wrote:
> On 23 Feb 2013, at 15:47, Bert Freudenberg<[hidden email]> wrote: >> Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts? > > The reason it doesn't already do this is just that I didn't want to annoy everyone. I think it's a great idea. What granularity ought to apply? Mails on new issues? State changes (to see when something's resolved)? Actually, there is no easy way to do this with Mantis. I've just spent some time looking into it and there is no official support for sending email to a specific email address every time a new issue is created or any activity occurs on an issue. It's not impossible to implement; it can be done by writing a custom hook. But this is not an ideal solution because you have to take care to ensure the custom hooks are reinstalled every time you update Mantis and on occasion the hook may be broken due to changes in Mantis. Also, clearly the community has never been entirely comfortable with Mantis. Frankly I think this is a very good time, certainly as good as any, to reconsider how we track issues. It's all going to have to be setup again from scratch soon anyway. I've personally always felt that that something integrated into Squeak itself (well, an installable package anyway) is the way for us to go, something customized to how we are accustomed to working and probably hooking into Monticello. But making any such thing will be a lot of work and someone has to step up to do it and take the risk that the community will not find the result actually usable/acceptable. One other choice I think is worth some consideration is to 'out-source' our bug tracking. This is not without potential problems. But I noticed that Eliot is using code.google.com for Cog and a quick look at the documentation (and the fact that emails are appearing on vm-dev) suggests that this one feature, sending notices to a given address for every issue, is supported by Google Code. Ken |
Re: Let's consider changing how we track issues (was Re: [squeak-dev] Mantis usage rules du jour)
|
|
I see SqueakSource3 has a Issues category per package. For example: On Sat, Feb 23, 2013 at 11:52 PM, Ken Causey <[hidden email]> wrote: On 02/23/2013 10:09 AM, Frank Shearar wrote: |
Re: Let's consider changing how we track issues (was Re: [squeak-dev] Mantis usage rules du jour)
|
|
On 02/23/2013 05:15 PM, karl ramberg wrote:
> I see SqueakSource3 has a Issues category per package. > > For example: > http://ss3.gemstone.com/ss/dgg.html/Issues > > Karl Nice, thanks for pointing that out. There has been some discussion of setting up a SqueakSource3 instance as an upgrade to source.squeak.org but I think the consensus is that it is not ready yet to support all of the Monticello capabilities we currently use, I'm not sure of the details. Can you collect some details about how the Issue tracking works, for example whether there is support for sending email to a specific email address for every new issue or each time an issue is updated? Also is it up to handling hundreds or even thousands of issues? I created an account and considered creating a temporary project for evaluation purposes. But I'm holding off because I don't want to create such a project and then find that I can't easily delete it and pollute the project list. Ken |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |