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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XO: Execute Operator
On 22 February 2013 22:27, tim Rowledge tim@rowledge.org 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
On Fri, Feb 22, 2013 at 2:41 PM, Frank Shearar frank.shearar@gmail.comwrote:
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.)
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
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 colin@wiresong.com wrote:
On Fri, Feb 22, 2013 at 2:41 PM, Frank Shearar frank.shearar@gmail.comwrote:
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.)
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
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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Casey Ransberger Sent: Friday, February 22, 2013 11:58 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] 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 colin@wiresong.com wrote:
On Fri, Feb 22, 2013 at 2:41 PM, Frank Shearar frank.shearar@gmail.com wrote:
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.)
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
On 22-02-2013, at 8:50 PM, Colin Putney colin@wiresong.com 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; tim@rowledge.org; http://www.rowledge.org/tim Is reading in the bathroom considered Multi-Tasking?
On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge tim@rowledge.org 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-mode...
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
On Sat, Feb 23, 2013 at 12:33:14AM -0800, Colin Putney wrote:
On Fri, Feb 22, 2013 at 10:12 PM, tim Rowledge tim@rowledge.org 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-mode...
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?
On 23.02.2013, at 15:14, "David T. Lewis" lewis@mail.msen.com 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 tim@rowledge.org 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-mode...
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:
Mantis might appear less dead if reports/changes got posted to squeak-dev. Thoughts?
- Bert -
On 23 Feb 2013, at 15:47, Bert Freudenberg bert@freudenbergs.de wrote:
On 23.02.2013, at 15:14, "David T. Lewis" lewis@mail.msen.com 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 tim@rowledge.org 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-mode...
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:
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 -
On Sat, Feb 23, 2013 at 04:09:04PM +0000, Frank Shearar wrote:
On 23 Feb 2013, at 15:47, Bert Freudenberg bert@freudenbergs.de 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
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar frank.shearar@gmail.comwrote:
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
On 23.02.2013, at 19:02, Colin Putney colin@wiresong.com wrote:
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar frank.shearar@gmail.com 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 -
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Saturday, February 23, 2013 1:22 PM
On 23.02.2013, at 19:02, Colin Putney colin@wiresong.com wrote:
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar frank.shearar@gmail.com
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 -
Bugs is good because of bugs.squeak.org and mantis does come from bug. I thought about bugs first but was thinking that we don't use mantis to document bugs only. We use it for new code, for making changes to working code and such. It works fine for me but I wonder if the name would prevent some people from using it, or would it cause some confusion.
[Squeak-dev] should really be [commits]. Maybe [Bugs] should be [changes] or [discuss].
Ron
On 24.02.2013, at 19:51, "Ron Teitelbaum" ron@usmedrec.com wrote:
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Saturday, February 23, 2013 1:22 PM
On 23.02.2013, at 19:02, Colin Putney colin@wiresong.com wrote:
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar frank.shearar@gmail.com
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 -
Bugs is good because of bugs.squeak.org and mantis does come from bug. I thought about bugs first but was thinking that we don't use mantis to document bugs only. We use it for new code, for making changes to working code and such. It works fine for me but I wonder if the name would prevent some people from using it, or would it cause some confusion.
[Squeak-dev] should really be [commits]. Maybe [Bugs] should be [changes] or [discuss].
Ron
[squeak-dev] is added to all mails by the list software.
[Bugs] would be in addition.
Actually, since we don't have a [tag] for commit messages either, maybe we don't need them, as long as the rest of the generated subject still allows filtering?
- Bert -
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg
On 24.02.2013, at 19:51, "Ron Teitelbaum" ron@usmedrec.com wrote:
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Saturday, February 23, 2013 1:22 PM
On 23.02.2013, at 19:02, Colin Putney colin@wiresong.com wrote:
On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar frank.shearar@gmail.com
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 -
Bugs is good because of bugs.squeak.org and mantis does come from bug. I thought about bugs first but was thinking that we don't use mantis to document bugs only. We use it for new code, for making changes to working code and such. It works fine for me but I wonder if the name would prevent some people from using it, or would it cause some
confusion.
[Squeak-dev] should really be [commits]. Maybe [Bugs] should be [changes] or [discuss].
Ron
[squeak-dev] is added to all mails by the list software.
[Bugs] would be in addition.
Actually, since we don't have a [tag] for commit messages either, maybe we don't need them, as long as the rest of the generated subject still allows filtering?
You are right. That was silly. I agree.
I don't filter out commits but since they come from commits@source.squeak.org that would be good enough. If mantis comes from bugs@source.squeak.org that would be enough too.
Could we add a footer to the email from bugs that says this is the place for discussing specific changes to squeak, suggesting new code, or reporting bugs.
Ron
- Bert -
On 02/23/2013 10:09 AM, Frank Shearar wrote:
On 23 Feb 2013, at 15:47, Bert Freudenbergbert@freudenbergs.de 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
I see SqueakSource3 has a Issues category per package.
For example: http://ss3.gemstone.com/ss/dgg.html/Issues
Karl
On Sat, Feb 23, 2013 at 11:52 PM, Ken Causey ken@kencausey.com wrote:
On 02/23/2013 10:09 AM, Frank Shearar wrote:
On 23 Feb 2013, at 15:47, Bert Freudenberg<bert@freudenbergs.**debert@freudenbergs.de> 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
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
I'm no expert on SqueakSource3, maybe there is someone who have deeper knowledge that can share ?
On Sun, Feb 24, 2013 at 12:28 AM, Ken Causey ken@kencausey.com wrote:
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/Issueshttp://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.orgbut 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
Am 24.02.2013 um 20:51 schrieb karl ramberg karlramberg@gmail.com:
I'm no expert on SqueakSource3, maybe there is someone who have deeper knowledge that can share ?
That would be me…
The “Issues” feature of SS3 is a proof-of-concept by Dale that works quite well but is not as advanced as say Mantis, Google Code or Github. Some students tried enhancing the Issues feature by auto-close on commit message and so on, but time ran out for their project. That said, if you browse http://www.squeaksource.com/squeaksource3.html (Latest, SqueakSource-Issues-topa.17.mcz, Browse code) you’ll see that the original Issue feature is not too much code.
Give it a shot:
Installer ss project: 'MetacelloRepostiory'; install: 'ConfigurationOfSqueakSource3'. ((Smalltalk at: #ConfigurationOfSqueakSource3) project version: #bleedingEdge) load: #( 'All' )
[This assumes that Seaside can be loaded, which currently is not the case, actually :/. The SqueakSource3 code is Squeak-compatible, but loading OB/Seaside is still not working, but out of scope here]
When you have loaded Squeaksource, and a Seaside Adaptor is running, go to the url /installSS and install a SqueakSource instance (best with a DictionaryStorage for playing around). Then, add a user and a test project and be sure to enable the Issues feature during project creation. Then, start hacking along :)
Best -Tobias
PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote:
PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Am 25.02.2013 um 14:26 schrieb radoslav hodnicak rh@4096.sk:
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote: PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Well, there is https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st which explicitely _does_ use Metacello and https://github.com/renggli/builder/blob/master/scripts/seaside3.st which explicitely _does not_ use Metacello.
If you were an “image distributor”, ie, someone who hands images to other developers, which one would you take? Which resulting image is easier to update? Which script is easier to maintain? (Sorry the many questions, not meant to be offensive :) )
Best -Tobias
On 2013-02-25, at 14:56, Tobias Pape Das.Linux@gmx.de wrote:
Am 25.02.2013 um 14:26 schrieb radoslav hodnicak rh@4096.sk:
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote: PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Well, there is https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st which explicitely _does_ use Metacello and https://github.com/renggli/builder/blob/master/scripts/seaside3.st which explicitely _does not_ use Metacello.
If you were an “image distributor”, ie, someone who hands images to other developers, which one would you take? Which resulting image is easier to update? Which script is easier to maintain? (Sorry the many questions, not meant to be offensive :) )
Best -Tobias
Well, in the first one the complexity is just hidden, distributed over many packages in various repositories, which seems hard to control for an individual image builder. As you discovered, it drags in many unneeded pieces - Zinc, OB, really? So if you want to build a clean image right now then it seems indeed avoiding Metacello would make your live easier. I don't know how much effort it would take to sanitize all the various configs it loads? Since you gave up after several hours, I guess a lot of effort (although I would be delighted to be proven wrong). But it sounds like it might not have taken you several hours to adapt the second script to your needs.
I do see the chicken-and-egg problem here. Maybe distilling Lukas' script into a squeakmap loader would make it easier to install Seaside, which might in turn get more Squeakers to actively participate in its development, which might lead to properly maintained Metacello configurations. Or, since you mention Metacello bootstrapping problems, do we need to fix Metacello itself first? Depending on a particular browser does not sound right for a package installer.
- Bert -
On 25 February 2013 14:20, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-25, at 14:56, Tobias Pape Das.Linux@gmx.de wrote:
Am 25.02.2013 um 14:26 schrieb radoslav hodnicak rh@4096.sk:
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote: PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Well, there is https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st which explicitely _does_ use Metacello and https://github.com/renggli/builder/blob/master/scripts/seaside3.st which explicitely _does not_ use Metacello.
If you were an “image distributor”, ie, someone who hands images to other developers, which one would you take? Which resulting image is easier to update? Which script is easier to maintain? (Sorry the many questions, not meant to be offensive :) )
Best -Tobias
Well, in the first one the complexity is just hidden, distributed over many packages in various repositories, which seems hard to control for an individual image builder. As you discovered, it drags in many unneeded pieces - Zinc, OB, really? So if you want to build a clean image right now then it seems indeed avoiding Metacello would make your live easier. I don't know how much effort it would take to sanitize all the various configs it loads? Since you gave up after several hours, I guess a lot of effort (although I would be delighted to be proven wrong). But it sounds like it might not have taken you several hours to adapt the second script to your needs.
Don't forget that Metacello is expressly designed to work _across platforms_. If all you care about is only one of Pharo, or Squeak, or Gemstone, or VW, then Metacello is overkill. However, if you try adapt your script to support all of these, you'll have just reinvented Metacello.
Metacello _does_ have issues, but "hiding complexity" is not one of them.
I do see the chicken-and-egg problem here. Maybe distilling Lukas' script into a squeakmap loader would make it easier to install Seaside, which might in turn get more Squeakers to actively participate in its development, which might lead to properly maintained Metacello configurations. Or, since you mention Metacello bootstrapping problems, do we need to fix Metacello itself first? Depending on a particular browser does not sound right for a package installer.
Metacello doesn't depend on OmniBrowser. (It does depend on Gofer, but otherwise it's just Collections, Compiler, Compression, Exceptions, Files, HelpSystem-Core, Kernel, Monticello, PackageInfo-Base, SUnit and System.).
What usually happens is that some particular package depends on OB (for instance, Helvetia uses OBMorphicIcons), which is not Metacello's fault at all.
frank
- Bert -
Am 25.02.2013 um 15:20 schrieb Bert Freudenberg bert@freudenbergs.de:
On 2013-02-25, at 14:56, Tobias Pape Das.Linux@gmx.de wrote:
Am 25.02.2013 um 14:26 schrieb radoslav hodnicak rh@4096.sk:
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote: PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Well, there is https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st which explicitely _does_ use Metacello and https://github.com/renggli/builder/blob/master/scripts/seaside3.st which explicitely _does not_ use Metacello.
If you were an “image distributor”, ie, someone who hands images to other developers, which one would you take? Which resulting image is easier to update? Which script is easier to maintain? (Sorry the many questions, not meant to be offensive :) )
Best -Tobias
Well, in the first one the complexity is just hidden, distributed over many packages in various repositories, which seems hard to control for an individual image builder. As you discovered, it drags in many unneeded pieces - Zinc, OB, really?
Stop. It drags OB for the _developer_ image, which is consistent, IMHO. Why it did pull Zinc on the first try, I don't know. Later, It pulled Kom instead of Zinc.
So if you want to build a clean image right now then it seems indeed avoiding Metacello would make your live easier. I don't know how much effort it would take to sanitize all the various configs it loads? Since you gave up after several hours, I guess a lot of effort (although I would be delighted to be proven wrong). But it sounds like it might not have taken you several hours to adapt the second script to your needs.
No. It was not the problem of Metacello in that case but that there are conflicting methods of loading Omnibrowser floating around. I _wanted_ OB in the Image I tried to produce. It is, eg, necessary for the Seaside Control Panel.
I do see the chicken-and-egg problem here. Maybe distilling Lukas' script into a squeakmap loader would make it easier to install Seaside, which might in turn get more Squeakers to actively participate in its development, which might lead to properly maintained Metacello configurations.
The paths sounds interesting. But, I think, this is the path required for Omnibrowser, not for Seaside. Once OB is pulling in fine, Seaside-Development is a no-brainer.
Issuing Installer ss project: 'MetacelloRepository'; install: 'ConfigurationOfSeaside30'. ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load: #( Base ) works fine and produces a nice Seaside image _without_ developer tools (ie, no Seaside Control Panel, no pre-selected Adaptor)
However, when you try to load the Development branch, it depends on Omnibrowser. And that thing is broken XD
Probably I just should invest the time and Fix the Omnibrowser Metacelllo package, hoping that this is the root cause. Expect me in a few hours.
Or, since you mention Metacello bootstrapping problems, do we need to fix Metacello itself first? Depending on a particular browser does not sound right for a package installer.
Again, it is not a Metacello bootstrapping problem but an Omnibrowser bootstrapping problem.
Best -Tobias
(DISCLAIMER: don't take me too serious today, I'm a bit pissed, but I will be ok tomorrow ;) )
Probably I just should invest the time and Fix the Omnibrowser Metacelllo package, hoping that this is the root cause. Expect me in a few hours.
Ok, since my version is a bit old I'll hold off for you. Thanks Tobias.
Am 25.02.2013 um 21:48 schrieb Chris Muller asqueaker@gmail.com:
Probably I just should invest the time and Fix the Omnibrowser Metacelllo package, hoping that this is the root cause. Expect me in a few hours.
Ok, since my version is a bit old I'll hold off for you. Thanks Tobias.
OB works again, Seaside not yet (see my other mails). Shall I provide an image to you for download?
Best -Tobias
This is not exactly the answer to your question, but I prefer the second (seaside3.st). I have some seaside images that I do stuff in from time to time, the most recent being a 4.3 image. I was a bit amused by recent indications on this list that seaside was not loading in the latest Squeak and thought, there's another reason to stay with what works. If, however, the urge to get Seaside on the very latest Squeak overcame me, I would much prefer trying to debug the second rather than the first.
Cheers, Bob
On 2/25/13 8:56 AM, Tobias Pape wrote:
Am 25.02.2013 um 14:26 schrieb radoslav hodnicak rh@4096.sk:
On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape Das.Linux@gmx.de wrote: PS: Off-topic but IMHO important. I started replying to this email 7:30 AM and got stuck at the installation instructions and now I send this mail at 1 PM; I, sadly, have to conclude: Installing a proper development image for Seaside on Squeak is still a mess. I was the one who provided the Squeak Seaside image for Squeak 4.3 but currently I see myself completely unable to set up Seaside for Squeak 4.4. Just some random notes to relieve me: • Installing Seaside need Metacello. • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing and completely unavailable for Squeak • Bootstrapping metacello needs Omnibrowser basics • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is completely broken. Remember the not working buttons? still there. • First installing OmniBrowser via Coiln’s script and then loading anything via Metacello that depends on OB: boom • First installing Omnibrowser via Metacello, then loading via Colin’s script: no boom, but conflicting Classes. need to remove OB-Morphic manually... • at _that_ point I gave up.
I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
rado
Well, there is https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st which explicitely _does_ use Metacello and https://github.com/renggli/builder/blob/master/scripts/seaside3.st which explicitely _does not_ use Metacello.
If you were an “image distributor”, ie, someone who hands images to other developers, which one would you take? Which resulting image is easier to update? Which script is easier to maintain? (Sorry the many questions, not meant to be offensive :) )
Best -Tobias
[This assumes that Seaside can be loaded, which currently is not the case, actually :/.
I have a configuration of Seaside 3.0 or 3.1 (can't remember) which loads fine in a 4.4 image as well as trunk and does NOT require OB or Metacello. I'll see about making a catalog entry..
Hey guys!
On 02/23/2013 11:52 PM, Ken Causey wrote:
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.
Just as a ... well, "data point":
At 3DICC we fairly recently took charge of this and I scanned the market a bit looking at Trac and a few others, even tried installing Trac (liked their idea of marrying a wiki with issue tracker) but that was a PITA.
Then I tried Redmine - which basically is a reimplementation of similar ideas but in Rails, and wow, that was very simple to get set up and it does AFAICT everything you want and is quite easy to customize - just by clicking around in the admin UIs.
It has integrated wiki blabla, and also support for SVN/git etc, and I wouldn't be surprised if you fairly easily could do a commit hook at least for MC. Granted the first time I saw their website I didn't think it looked that nice, kinda boring - but if you start clicking around you quickly realize it is neat! Also very "REST"-ful, you know with nice URLs pointing to issues, the form for creating new issues blabla...
We are really satisfied at least. :)
regards, Göran
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Saturday, February 23, 2013 10:48 AM
On 23.02.2013, at 15:14, "David T. Lewis" lewis@mail.msen.com 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 tim@rowledge.org
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:
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 -
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
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 tim@rowledge.org wrote:
On 22-02-2013, at 8:50 PM, Colin Putney colin@wiresong.com 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; tim@rowledge.org; http://www.rowledge.org/tim Is reading in the bathroom considered Multi-Tasking?
On 23 February 2013 06:12, tim Rowledge tim@rowledge.org wrote:
On 22-02-2013, at 8:50 PM, Colin Putney colin@wiresong.com 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; tim@rowledge.org; http://www.rowledge.org/tim Is reading in the bathroom considered Multi-Tasking?
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
Casey Ransberger -
Chris Muller -
Colin Putney -
David T. Lewis -
Frank Shearar -
Göran Krampe -
karl ramberg -
Ken Causey -
radoslav hodnicak -
Ron Teitelbaum -
Stéphane Rollandin -
tim Rowledge -
Tobias Pape