A process proposal for 3.10
Locked
12345
... 7
12345
... 7
 
|
I agree with Andreas. But I think we should consider the possibility of
the community to pay for someone to do some of the dirty work, for example to make the maintenance of the process easier. There have been people willing to put up money for projects like this. We could identify what are the big bottlenecks in the process and what can be done about them. Then we can look for a reasonable solution and make a offer/bounty for a solution. Karl Andreas Raab skrev: > Hi Giovanni - > > I fully agree with the meta goals of your proposal, namely to enable > people to do their own development and to limit the amount of time > spend on each individual part of the release. > > That said, I'm in almost complete disagreement with the rest of your > proposal ;-) The fundamental flaw in it is that you are trying to > commit other people's time. Starting from "the board appoints a > release team" (phase 0) over "the teams announce the development > plans" (phase 1) and "code will get dropped" (phase 2) up until "the > VMMaker team will want to..." (the example) you're happy committing > other people's time. In my experience this has *always* been a fatal > error in a volunteer open source project. > > The *only* time you can commit is your own. And given that, how much > of your proposal works if the only time that you can count on is your > own? Even if we want to change the release process we cannot change > some fundamentals about the environment we're in. And one of those > fundamentals is that (on a scale where it matters) you can't tell > people what to do. They're doing it voluntarily, they're doing it for > their own reasons and trying to change that simply won't work. To > give a more concrete example, the maintenance work I do for FFI, > Graphics, Balloon, and Compression packages is purely a volunteer > effort. If you ask me about my "development plans" for the next six > months, all I can say is "uhm ... ". Most importantly, because I have > a fulltime job in a startup I for example couldn't possibly commit to > a six months active development plan. It's simply not doable and even > if it were I'd reject it on the grounds that unless you pay me for it > I'm not going to treat this serious enough to make six month plans ;-) > > Both Stef and Markus understand that basic point. They both understand > that in reality, all they can count on is their own time and they have > reacted by investing more and more of their own time and effort in the > process. And I would like us to change that process from one that > leaves people burned out into one that can be done in a reasonable > amount of time with a sustainable amount of energy. > > That change starts by admitting that we're all volunteers. Whether > something will happen depends on so many factors that it's basically > useless to try to do serious upfront planning for it. And again this > is meant on scale - for each individual team it may make perfect sense > but on scale I think you really can't. > > To emphasize that point even more I'll give you two recent examples: > First, we have been talking for *years* about changing the source > pointer in the methods. That it happens *now* is (from my point of > view) exclusively due to the fact that we got a new sources file in > 3.9 and lost the entire previous history for the single reason of the > source limitations. Could anyone really have planned for that? I don't > think so. Second, the SSL implementation we got recently. A while ago > we started looking at SSL ourselves and decided to go with OpenSSL - > we talked about Crypto team and their work but honestly, I would have > called anyone a nut who would have told me that this stuff will be > ready by now (I probably would have just laughed them out of the > room). At least for me, this project came out of the blue, completely > unforeseen and again nothing you could have possibly planned for. > > My point here is (in case you haven't guessed it by now) that in a > volunteer community "planning" on the scale you are looking at is in > many ways a futile exercise. Things happen for their own reasons at > their own speed and not because you want them. And unless you want to > put in endless amounts of energy by developing all the stuff that > "your release" needs, you better find a way of dealing with that. > > Which brings me to the proposal I made earlier. The main goal of that > proposal is really to get away from the upfront feature planning > process and deal with the chaotic reality of open source development > by *embracing* it. So instead of feature list of things that we SHOULD > do, I'd like us to discuss things we HAVE done. Instead of wishful > thinking I'd like us to talk about all the cool stuff that is actually > happening! > > I think that this may be the only way to make sure we can survive the > release process in a volunteer community like ours and it's > surprisingly similar to what we did at SqC - the main difference is > that SqC (instead of the community) picked which of the contributions > got adopted and which ones didn't. At SqC (or any other commercial > entity that I have been involved in) we have always been aware of > error 33 and therefore never relied on the open source effort to > produce specific results in a specific time frame. That's what > companies do, that's why they take money to do it. However, anything > that happened was always welcome and often a surprise. And I can say > for sure that during those times nobody got burned out by the > process. And I think that process can be recreated. > > Cheers, > - Andreas > > Giovanni Corriga wrote: >> Hi all, >> >> since we've started discussing 3.10/4.0, I'd like to relay some thoughts >> that I've expressed some times ago on #squeak about a possible >> development process for Squeak 3.10. >> >> This proposal is based on two points: >> - decentralization of development >> - fixed duration of iterations ("timeboxing") >> >> "Decentralization of development" means moving most of the >> responsibility of development from the release team to the single >> package mantainers (stewards). The release team should just be an >> integrator of the code blessed by the stewards, and should facilitate >> coordination between the stewards of different packages. >> "Timeboxing" means having a fixed length release cycle, at the end of >> which a new stable version is released. This means that if there are >> some problems with a new feature, the deadline doesn't get postponed; >> instead it's the feature that gets dropped from the current development >> release and rescheduled for the next release. >> >> How would this work? Here's a more detailed description. >> ----------------------------------------------------------------------- >> PHASE 0: RELEASE TEAM FORMATION >> The SqF board will appoint a release team for 3.10. This team will have >> 3-7 members; 5 would be the sweet spot. >> The first task for the release team will be to find a mantainer for each >> one of the packages currently in the image. If they can't find a >> mantainer for a package, than said package _will get dropped from the >> image_ without any further discussion. >> >> PHASE 1: RELEASE PLAN >> After having found mantainers for every package, there's a package >> selection phase, during which the team and the maintainers: >> - decide which packages currently in the image should get removed from >> the image and turned into SqueakMap-loadable packages. >> - decide which new packages can be added to the image or replace other >> packages currently in the image. >> Input from the community and the stakeholders will be taken into >> account. >> >> After deciding which packages will be in the 3.10 image, the release >> team, the mantainers and the community will work on creating the release >> plan. >> Each package mantainer will announce what it plans to do for 3.10. The >> release team will integrate these proposals into a coherent release >> plan, solving possible conflicts and coordination problems. The >> community will be able to make comments and/or requests. >> >> After all these steps, which shouldn't take more than a month, the >> development of 3.10 can start. >> >> PHASE 2: DEVELOPMENT >> Development will have three stages: >> - a 3 months alpha stage >> - a 2 months beta stage >> - a 1 month gamma/RC stage. >> The deadline for each stage will be decided at the beginning of the >> iteration. >> Every week during each stage the release team will integrate the new >> releases of each package blessed by the package mantainers. >> >> Package mantainers will be the main responsible for development of their >> package and they'll be free to manage development as they like; ideally >> they should create a development team. >> >> If at the end of the alpha stage some of the work items of the plan >> aren't near completion, _these items and the corresponding code will get >> dropped_. If this is not possible, the code will be kept in the image, >> but it will have not to break the other code in the image. >> >> During the beta and gamma stages, no new features will get added to the >> image; only bug fixes can go in. During the gamma stage, only >> showstopper bugs will be fixed; other bug fixes (eg. cosmetical fixes) >> will be scheduled for 3.10.1. >> >> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or >> whatever) will get appointed and will work with the package mantainers >> to form the release plan for the next version. >> >> EXAMPLE >> Here's a an example of how things could possibly work. >> >> Release plan: >> During phase 1, the various package mantainers propose work items. So >> let's pretend that... >> - VMMaker team will want to: >> * integrate the async event patches useful for SqueakGtk. >> * integrate the Ffenestri code in all VMs, including the Unix one. >> * work with the Kernel team/maintainer on CompiledMethod cleanup. >> - Nebraska team will work on removing it from the image. >> - Pavel will want to work with various mantainers to integrate his >> patches for his KernelImage system. >> - Tools team will want to: >> * better integrate AST and the Refactoring services. >> * make Omnibrowser the default browser. >> >> Now let's pretend that at the end of the alpha stage, the Tools team >> still hasn't produced an Omnibrowser based debugger. Since it's the end >> of the alpha stage, the OBDebugger will be punted to the next release, >> and 3.10 will have a class browser based on OB but still the old >> debugger. >> ----------------------------------------------------------------------- >> >> I believe a process such as the one I'm proposing can work and help >> produce good quality releases. >> >> I'd like to hear comments on this, even if they just say that my >> proposal sucks. >> >> Ciao, >> >> Giovanni >> >> >> > > > |
Re: A process proposal for 3.10
|
|
We could use initiatives like the SummerTalk, to sponsor students to get
some needed work done in Squeak. It would involve finding a tutor willing to give time over the summer, and also to take(find?) the time to write the project plans. But it could be both a good experience for the student and a benefit to squeak and its users. It would also bring a satisfaction to the student, knowing his work is used :) Yann , SummerTalk student http://yann.monclair.fr/summertalk karl wrote: > I agree with Andreas. But I think we should consider the possibility of > the community to pay for someone to do some of the dirty work, for > example to make the maintenance of the process easier. There have been > people willing to put up money for projects like this. We could identify > what are the big bottlenecks in the process and what can be done about > them. Then we can look for a reasonable solution and make a offer/bounty > for a solution. > Karl > > > > > Andreas Raab skrev: >> Hi Giovanni - >> >> I fully agree with the meta goals of your proposal, namely to enable >> people to do their own development and to limit the amount of time >> spend on each individual part of the release. >> >> That said, I'm in almost complete disagreement with the rest of your >> proposal ;-) The fundamental flaw in it is that you are trying to >> commit other people's time. Starting from "the board appoints a >> release team" (phase 0) over "the teams announce the development >> plans" (phase 1) and "code will get dropped" (phase 2) up until "the >> VMMaker team will want to..." (the example) you're happy committing >> other people's time. In my experience this has *always* been a fatal >> error in a volunteer open source project. >> >> The *only* time you can commit is your own. And given that, how much >> of your proposal works if the only time that you can count on is your >> own? Even if we want to change the release process we cannot change >> some fundamentals about the environment we're in. And one of those >> fundamentals is that (on a scale where it matters) you can't tell >> people what to do. They're doing it voluntarily, they're doing it for >> their own reasons and trying to change that simply won't work. To >> give a more concrete example, the maintenance work I do for FFI, >> Graphics, Balloon, and Compression packages is purely a volunteer >> effort. If you ask me about my "development plans" for the next six >> months, all I can say is "uhm ... ". Most importantly, because I have >> a fulltime job in a startup I for example couldn't possibly commit to >> a six months active development plan. It's simply not doable and even >> if it were I'd reject it on the grounds that unless you pay me for it >> I'm not going to treat this serious enough to make six month plans ;-) >> >> Both Stef and Markus understand that basic point. They both understand >> that in reality, all they can count on is their own time and they have >> reacted by investing more and more of their own time and effort in the >> process. And I would like us to change that process from one that >> leaves people burned out into one that can be done in a reasonable >> amount of time with a sustainable amount of energy. >> >> That change starts by admitting that we're all volunteers. Whether >> something will happen depends on so many factors that it's basically >> useless to try to do serious upfront planning for it. And again this >> is meant on scale - for each individual team it may make perfect sense >> but on scale I think you really can't. >> >> To emphasize that point even more I'll give you two recent examples: >> First, we have been talking for *years* about changing the source >> pointer in the methods. That it happens *now* is (from my point of >> view) exclusively due to the fact that we got a new sources file in >> 3.9 and lost the entire previous history for the single reason of the >> source limitations. Could anyone really have planned for that? I don't >> think so. Second, the SSL implementation we got recently. A while ago >> we started looking at SSL ourselves and decided to go with OpenSSL - >> we talked about Crypto team and their work but honestly, I would have >> called anyone a nut who would have told me that this stuff will be >> ready by now (I probably would have just laughed them out of the >> room). At least for me, this project came out of the blue, completely >> unforeseen and again nothing you could have possibly planned for. >> >> My point here is (in case you haven't guessed it by now) that in a >> volunteer community "planning" on the scale you are looking at is in >> many ways a futile exercise. Things happen for their own reasons at >> their own speed and not because you want them. And unless you want to >> put in endless amounts of energy by developing all the stuff that >> "your release" needs, you better find a way of dealing with that. >> >> Which brings me to the proposal I made earlier. The main goal of that >> proposal is really to get away from the upfront feature planning >> process and deal with the chaotic reality of open source development >> by *embracing* it. So instead of feature list of things that we SHOULD >> do, I'd like us to discuss things we HAVE done. Instead of wishful >> thinking I'd like us to talk about all the cool stuff that is actually >> happening! >> >> I think that this may be the only way to make sure we can survive the >> release process in a volunteer community like ours and it's >> surprisingly similar to what we did at SqC - the main difference is >> that SqC (instead of the community) picked which of the contributions >> got adopted and which ones didn't. At SqC (or any other commercial >> entity that I have been involved in) we have always been aware of >> error 33 and therefore never relied on the open source effort to >> produce specific results in a specific time frame. That's what >> companies do, that's why they take money to do it. However, anything >> that happened was always welcome and often a surprise. And I can say >> for sure that during those times nobody got burned out by the >> process. And I think that process can be recreated. >> >> Cheers, >> - Andreas >> >> Giovanni Corriga wrote: >>> Hi all, >>> >>> since we've started discussing 3.10/4.0, I'd like to relay some thoughts >>> that I've expressed some times ago on #squeak about a possible >>> development process for Squeak 3.10. >>> >>> This proposal is based on two points: >>> - decentralization of development >>> - fixed duration of iterations ("timeboxing") >>> >>> "Decentralization of development" means moving most of the >>> responsibility of development from the release team to the single >>> package mantainers (stewards). The release team should just be an >>> integrator of the code blessed by the stewards, and should facilitate >>> coordination between the stewards of different packages. >>> "Timeboxing" means having a fixed length release cycle, at the end of >>> which a new stable version is released. This means that if there are >>> some problems with a new feature, the deadline doesn't get postponed; >>> instead it's the feature that gets dropped from the current development >>> release and rescheduled for the next release. >>> >>> How would this work? Here's a more detailed description. >>> ----------------------------------------------------------------------- >>> PHASE 0: RELEASE TEAM FORMATION >>> The SqF board will appoint a release team for 3.10. This team will have >>> 3-7 members; 5 would be the sweet spot. >>> The first task for the release team will be to find a mantainer for each >>> one of the packages currently in the image. If they can't find a >>> mantainer for a package, than said package _will get dropped from the >>> image_ without any further discussion. >>> >>> PHASE 1: RELEASE PLAN >>> After having found mantainers for every package, there's a package >>> selection phase, during which the team and the maintainers: >>> - decide which packages currently in the image should get removed from >>> the image and turned into SqueakMap-loadable packages. >>> - decide which new packages can be added to the image or replace other >>> packages currently in the image. >>> Input from the community and the stakeholders will be taken into >>> account. >>> >>> After deciding which packages will be in the 3.10 image, the release >>> team, the mantainers and the community will work on creating the release >>> plan. >>> Each package mantainer will announce what it plans to do for 3.10. The >>> release team will integrate these proposals into a coherent release >>> plan, solving possible conflicts and coordination problems. The >>> community will be able to make comments and/or requests. >>> >>> After all these steps, which shouldn't take more than a month, the >>> development of 3.10 can start. >>> >>> PHASE 2: DEVELOPMENT >>> Development will have three stages: >>> - a 3 months alpha stage >>> - a 2 months beta stage >>> - a 1 month gamma/RC stage. >>> The deadline for each stage will be decided at the beginning of the >>> iteration. >>> Every week during each stage the release team will integrate the new >>> releases of each package blessed by the package mantainers. >>> >>> Package mantainers will be the main responsible for development of their >>> package and they'll be free to manage development as they like; ideally >>> they should create a development team. >>> >>> If at the end of the alpha stage some of the work items of the plan >>> aren't near completion, _these items and the corresponding code will get >>> dropped_. If this is not possible, the code will be kept in the image, >>> but it will have not to break the other code in the image. >>> >>> During the beta and gamma stages, no new features will get added to the >>> image; only bug fixes can go in. During the gamma stage, only >>> showstopper bugs will be fixed; other bug fixes (eg. cosmetical fixes) >>> will be scheduled for 3.10.1. >>> >>> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or >>> whatever) will get appointed and will work with the package mantainers >>> to form the release plan for the next version. >>> >>> EXAMPLE >>> Here's a an example of how things could possibly work. >>> >>> Release plan: >>> During phase 1, the various package mantainers propose work items. So >>> let's pretend that... >>> - VMMaker team will want to: >>> * integrate the async event patches useful for SqueakGtk. >>> * integrate the Ffenestri code in all VMs, including the Unix one. >>> * work with the Kernel team/maintainer on CompiledMethod cleanup. >>> - Nebraska team will work on removing it from the image. >>> - Pavel will want to work with various mantainers to integrate his >>> patches for his KernelImage system. >>> - Tools team will want to: >>> * better integrate AST and the Refactoring services. >>> * make Omnibrowser the default browser. >>> >>> Now let's pretend that at the end of the alpha stage, the Tools team >>> still hasn't produced an Omnibrowser based debugger. Since it's the end >>> of the alpha stage, the OBDebugger will be punted to the next release, >>> and 3.10 will have a class browser based on OB but still the old >>> debugger. >>> ----------------------------------------------------------------------- >>> >>> I believe a process such as the one I'm proposing can work and help >>> produce good quality releases. >>> >>> I'd like to hear comments on this, even if they just say that my >>> proposal sucks. >>> >>> Ciao, >>> >>> Giovanni >>> >>> >>> >> >> >> > > |
Re: A process proposal for 3.10
|
|
In reply to this post by Andreas.Raab
I basically agree.
So in my proposal I was trying to see on what I want to work (based on the artefacts already there and also what could be vision) and see if other people are willing too. Just making the list of things that should be integrated and integrate them is a lot of time. In general I would love to stop harvest fixes and produce more fun stuff (but may be I'm a housekeeper that like to clean stuff), may be I should stop because my job is different now. Stef > Hi Giovanni - > > I fully agree with the meta goals of your proposal, namely to > enable people to do their own development and to limit the amount > of time spend on each individual part of the release. > > That said, I'm in almost complete disagreement with the rest of > your proposal ;-) The fundamental flaw in it is that you are trying > to commit other people's time. Starting from "the board appoints a > release team" (phase 0) over "the teams announce the development > plans" (phase 1) and "code will get dropped" (phase 2) up until > "the VMMaker team will want to..." (the example) you're happy > committing other people's time. In my experience this has *always* > been a fatal error in a volunteer open source project. > > The *only* time you can commit is your own. And given that, how > much of your proposal works if the only time that you can count on > is your own? Even if we want to change the release process we > cannot change some fundamentals about the environment we're in. And > one of those fundamentals is that (on a scale where it matters) you > can't tell people what to do. They're doing it voluntarily, they're > doing it for their own reasons and trying to change that simply > won't work. To give a more concrete example, the maintenance work > I do for FFI, Graphics, Balloon, and Compression packages is purely > a volunteer effort. If you ask me about my "development plans" for > the next six months, all I can say is "uhm ... ". Most importantly, > because I have a fulltime job in a startup I for example couldn't > possibly commit to a six months active development plan. It's > simply not doable and even if it were I'd reject it on the grounds > that unless you pay me for it I'm not going to treat this serious > enough to make six month plans ;-) > > Both Stef and Markus understand that basic point. They both > understand that in reality, all they can count on is their own time > and they have reacted by investing more and more of their own time > and effort in the process. And I would like us to change that > process from one that leaves people burned out into one that can be > done in a reasonable amount of time with a sustainable amount of > energy. > > That change starts by admitting that we're all volunteers. Whether > something will happen depends on so many factors that it's > basically useless to try to do serious upfront planning for it. And > again this is meant on scale - for each individual team it may make > perfect sense but on scale I think you really can't. > > To emphasize that point even more I'll give you two recent > examples: First, we have been talking for *years* about changing > the source pointer in the methods. That it happens *now* is (from > my point of view) exclusively due to the fact that we got a new > sources file in 3.9 and lost the entire previous history for the > single reason of the source limitations. Could anyone really have > planned for that? I don't think so. Second, the SSL implementation > we got recently. A while ago we started looking at SSL ourselves > and decided to go with OpenSSL - we talked about Crypto team and > their work but honestly, I would have called anyone a nut who would > have told me that this stuff will be ready by now (I probably would > have just laughed them out of the room). At least for me, this > project came out of the blue, completely unforeseen and again > nothing you could have possibly planned for. > > My point here is (in case you haven't guessed it by now) that in a > volunteer community "planning" on the scale you are looking at is > in many ways a futile exercise. Things happen for their own reasons > at their own speed and not because you want them. And unless you > want to put in endless amounts of energy by developing all the > stuff that "your release" needs, you better find a way of dealing > with that. > > Which brings me to the proposal I made earlier. The main goal of > that proposal is really to get away from the upfront feature > planning process and deal with the chaotic reality of open source > development by *embracing* it. So instead of feature list of things > that we SHOULD do, I'd like us to discuss things we HAVE done. > Instead of wishful thinking I'd like us to talk about all the cool > stuff that is actually happening! > > I think that this may be the only way to make sure we can survive > the release process in a volunteer community like ours and it's > surprisingly similar to what we did at SqC - the main difference is > that SqC (instead of the community) picked which of the > contributions got adopted and which ones didn't. At SqC (or any > other commercial entity that I have been involved in) we have > always been aware of error 33 and therefore never relied on the > open source effort to produce specific results in a specific time > frame. That's what companies do, that's why they take money to do > it. However, anything that happened was always welcome and often a > surprise. And I can say for sure that during those times nobody got > burned out by the process. And I think that process can be recreated. > > Cheers, > - Andreas > > Giovanni Corriga wrote: >> Hi all, >> since we've started discussing 3.10/4.0, I'd like to relay some >> thoughts >> that I've expressed some times ago on #squeak about a possible >> development process for Squeak 3.10. >> This proposal is based on two points: >> - decentralization of development >> - fixed duration of iterations ("timeboxing") >> "Decentralization of development" means moving most of the >> responsibility of development from the release team to the single >> package mantainers (stewards). The release team should just be an >> integrator of the code blessed by the stewards, and should facilitate >> coordination between the stewards of different packages. >> "Timeboxing" means having a fixed length release cycle, at the end of >> which a new stable version is released. This means that if there are >> some problems with a new feature, the deadline doesn't get postponed; >> instead it's the feature that gets dropped from the current >> development >> release and rescheduled for the next release. >> How would this work? Here's a more detailed description. >> --------------------------------------------------------------------- >> -- >> PHASE 0: RELEASE TEAM FORMATION >> The SqF board will appoint a release team for 3.10. This team will >> have >> 3-7 members; 5 would be the sweet spot. >> The first task for the release team will be to find a mantainer >> for each >> one of the packages currently in the image. If they can't find a >> mantainer for a package, than said package _will get dropped from the >> image_ without any further discussion. >> PHASE 1: RELEASE PLAN >> After having found mantainers for every package, there's a package >> selection phase, during which the team and the maintainers: >> - decide which packages currently in the image should get removed >> from >> the image and turned into SqueakMap-loadable packages. >> - decide which new packages can be added to the image or replace >> other >> packages currently in the image. >> Input from the community and the stakeholders will be taken into >> account. >> After deciding which packages will be in the 3.10 image, the release >> team, the mantainers and the community will work on creating the >> release >> plan. >> Each package mantainer will announce what it plans to do for 3.10. >> The >> release team will integrate these proposals into a coherent release >> plan, solving possible conflicts and coordination problems. The >> community will be able to make comments and/or requests. >> After all these steps, which shouldn't take more than a month, the >> development of 3.10 can start. >> PHASE 2: DEVELOPMENT >> Development will have three stages: >> - a 3 months alpha stage >> - a 2 months beta stage >> - a 1 month gamma/RC stage. >> The deadline for each stage will be decided at the beginning of the >> iteration. >> Every week during each stage the release team will integrate the new >> releases of each package blessed by the package mantainers. >> Package mantainers will be the main responsible for development of >> their >> package and they'll be free to manage development as they like; >> ideally >> they should create a development team. >> If at the end of the alpha stage some of the work items of the plan >> aren't near completion, _these items and the corresponding code >> will get >> dropped_. If this is not possible, the code will be kept in the >> image, >> but it will have not to break the other code in the image. >> During the beta and gamma stages, no new features will get added >> to the >> image; only bug fixes can go in. During the gamma stage, only >> showstopper bugs will be fixed; other bug fixes (eg. cosmetical >> fixes) >> will be scheduled for 3.10.1. >> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or >> whatever) will get appointed and will work with the package >> mantainers >> to form the release plan for the next version. >> EXAMPLE >> Here's a an example of how things could possibly work. >> Release plan: >> During phase 1, the various package mantainers propose work items. So >> let's pretend that... >> - VMMaker team will want to: >> * integrate the async event patches useful for SqueakGtk. >> * integrate the Ffenestri code in all VMs, including the Unix >> one. >> * work with the Kernel team/maintainer on CompiledMethod cleanup. >> - Nebraska team will work on removing it from the image. >> - Pavel will want to work with various mantainers to integrate his >> patches for his KernelImage system. >> - Tools team will want to: >> * better integrate AST and the Refactoring services. >> * make Omnibrowser the default browser. >> Now let's pretend that at the end of the alpha stage, the Tools team >> still hasn't produced an Omnibrowser based debugger. Since it's >> the end >> of the alpha stage, the OBDebugger will be punted to the next >> release, >> and 3.10 will have a class browser based on OB but still the old >> debugger. >> --------------------------------------------------------------------- >> -- >> I believe a process such as the one I'm proposing can work and help >> produce good quality releases. >> I'd like to hear comments on this, even if they just say that my >> proposal sucks. >> Ciao, >> Giovanni > > |
Re: A process proposal for 3.10
|
|
In reply to this post by karl-8
:)
[ left blank on purpose ] > I agree with Andreas. But I think we should consider the > possibility of the community to pay for someone to do some of the > dirty work, for example to make the maintenance of the process > easier. There have been people willing to put up money for projects > like this. We could identify what are the big bottlenecks in the > process and what can be done about them. Then we can look for a > reasonable solution and make a offer/bounty for a solution. > Karl |
Re: A process proposal for 3.10
|
|
In reply to this post by Andreas.Raab
Il giorno lun, 16/10/2006 alle 21.45 -0700, Andreas Raab ha scritto:
> Hi Giovanni - Hi Andreas, thanks for your detailed reply. My comments are after the various sections of your message. > I fully agree with the meta goals of your proposal, namely to enable > people to do their own development and to limit the amount of time spend > on each individual part of the release. > > That said, I'm in almost complete disagreement with the rest of your > proposal ;-) The fundamental flaw in it is that you are trying to commit > other people's time. Starting from "the board appoints a release team" > (phase 0) over "the teams announce the development plans" (phase 1) and > "code will get dropped" (phase 2) up until "the VMMaker team will want > to..." (the example) you're happy committing other people's time. In my > experience this has *always* been a fatal error in a volunteer open > source project. Well, that goes against what I had in mind. My point was allowing the various team and developer to declare how much time they can commit in the coming months, and then plan accordingly. I should have expressed this explicitly. Also, most of the features would have already be developed independently from this cycle, and only integration and minor bug fixing should be required, unless there' a guarentee that missing feature will be completed. >From this point of view my example was too optimistic. > The *only* time you can commit is your own. And given that, how much of > your proposal works if the only time that you can count on is your own? > Even if we want to change the release process we cannot change some > fundamentals about the environment we're in. And one of those > fundamentals is that (on a scale where it matters) you can't tell people > what to do. They're doing it voluntarily, they're doing it for their own > reasons and trying to change that simply won't work. To give a more > concrete example, the maintenance work I do for FFI, Graphics, Balloon, > and Compression packages is purely a volunteer effort. If you ask me > about my "development plans" for the next six months, all I can say is > "uhm ... ". Most importantly, because I have a fulltime job in a startup > I for example couldn't possibly commit to a six months active > development plan. It's simply not doable and even if it were I'd reject > it on the grounds that unless you pay me for it I'm not going to treat > this serious enough to make six month plans ;-) In your case, according to the process I'm proposing, you would just declare that you can't commit any predetermined time for the next six months. Now, what if a couple of months after your declaration you have some time to work on, say, Graphics, and you're able to produce new releases of that package? If when this happens 3.10 is still in alpha, your new releases could be included without many problems (excluding integration problems, that is); if in beta or gamma, then your changes should be moved to the next version. But this would not forbid you to work on it; it would just postpone its integration. > To emphasize that point even more I'll give you two recent examples: > First, we have been talking for *years* about changing the source > pointer in the methods. That it happens *now* is (from my point of view) > exclusively due to the fact that we got a new sources file in 3.9 and > lost the entire previous history for the single reason of the source > limitations. Could anyone really have planned for that? I don't think > so. Second, the SSL implementation we got recently. A while ago we > started looking at SSL ourselves and decided to go with OpenSSL - we > talked about Crypto team and their work but honestly, I would have > called anyone a nut who would have told me that this stuff will be ready > by now (I probably would have just laughed them out of the room). At > least for me, this project came out of the blue, completely unforeseen > and again nothing you could have possibly planned for. And I would not have planned for it, too. On the other hand, _integration_ of such efforts in the main image needs a little planning. > Which brings me to the proposal I made earlier. The main goal of that > proposal is really to get away from the upfront feature planning process > and deal with the chaotic reality of open source development by > *embracing* it. So instead of feature list of things that we SHOULD do, > I'd like us to discuss things we HAVE done. Instead of wishful thinking > I'd like us to talk about all the cool stuff that is actually happening! > > I think that this may be the only way to make sure we can survive the > release process in a volunteer community like ours and it's surprisingly > similar to what we did at SqC - the main difference is that SqC (instead > of the community) picked which of the contributions got adopted and > which ones didn't. At SqC (or any other commercial entity that I have > been involved in) we have always been aware of error 33 and therefore > never relied on the open source effort to produce specific results in a > specific time frame. That's what companies do, that's why they take > money to do it. However, anything that happened was always welcome and > often a surprise. And I can say for sure that during those times nobody > got burned out by the process. And I think that process can be recreated. Ok, then would it be possible to integrate my proposal with yours? Giovanni |
Re: A process proposal for 3.10
|
|
In reply to this post by Andreas.Raab
On Mon, Oct 16, 2006 at 09:45:26PM -0700, Andreas Raab wrote:
> > Which brings me to the proposal I made earlier. The main goal of that > proposal is really to get away from the upfront feature planning process > and deal with the chaotic reality of open source development by > *embracing* it. So instead of feature list of things that we SHOULD do, > I'd like us to discuss things we HAVE done. Instead of wishful thinking > I'd like us to talk about all the cool stuff that is actually happening! +1 Dave |
|
|
David T. Lewis wrote:
> On Mon, Oct 16, 2006 at 09:45:26PM -0700, Andreas Raab wrote: > >>Which brings me to the proposal I made earlier. The main goal of that >>proposal is really to get away from the upfront feature planning process >>and deal with the chaotic reality of open source development by >>*embracing* it. So instead of feature list of things that we SHOULD do, >>I'd like us to discuss things we HAVE done. Instead of wishful thinking >>I'd like us to talk about all the cool stuff that is actually happening! > > > +1 > > Dave +1 more, all that up front planning feels a lot like waterfall, Smalltalker's most of all, should know better. |
|
|
In reply to this post by Pavel Krivanek
"Pavel Krivanek" <[hidden email]> writes:
> Very good notes. This problems are described in the thread with Stef's > postmortem analysis > (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/109807.html) It is just painful reading Stephane's description of package slices. Why not use Package Universes to organize a collection of package versions? There would be a 3.10 release universe. The release team would know the update password, and they could update that universe with new package versions as they see fit. Just give me the word, and I'd be happy to set up a server for you to experiment with. -Lex |
|
|
In reply to this post by Giovanni Corriga
Giovanni Corriga <[hidden email]> writes:
> My opinion is that then we should reduce the scope of the release until > it's manageable. Removing many packages from the image should ease this > problems until we have better tools, too. Removing dependencies is great, but it is a process that will not have huge success within the next 6 or even 12 months. For the next year, at least, we should be prepared to deal with an inter-dependent core image. The stewards approach is great for this. You can appoint a collections steward or a morphic steward even if the associated code is still highly inter-dependent with the rest of the image. -Lex |
|
|
In reply to this post by Giovanni Corriga
Giovanni Corriga <[hidden email]> writes:
> The problem with things like Etoys is that they're highly coupled with > the rest of the system, and part of the system depend on it. For > example, trying to remove Etoys triggers an emergency evaluator in > Squeak 3.9RC2. As I see it, if we want to remove Etoys (and either let > it rot in absence of a mantainer or turn it into an installable > package), those couplings would become bugs for the other package > mantainers. I agree with most of the thread. Let me toss in, though, I am not convinced that EToys being intertwined is necessarily a terrible thing. EToys is a lot of what makes Squeak, Squeak. You cannot unload the processes module from the Linux kernel. This is not a bad thing, because processes are part of what makes Linux, Linux. Also, keep in mind that all the Squeakland people are vitally interested in EToys. There are ETosy-based text books, for goodness' sakes. I do agree that at least one steward for EToys needs to be identified, if there is not one already. Try probing on the Squeakland mailing list, if nothing else. -Lex |
Re: "slices" of packages (was: A process proposal for 3.10)
|
|
In reply to this post by Lex Spoon
On 17 Oct 2006 10:49:11 -0400, Lex Spoon <[hidden email]> wrote:
> "Pavel Krivanek" <[hidden email]> writes: > > Very good notes. This problems are described in the thread with Stef's > > postmortem analysis > > (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/109807.html) > > > It is just painful reading Stephane's description of package slices. > > Why not use Package Universes to organize a collection of package > versions? There would be a 3.10 release universe. The release team > would know the update password, and they could update that universe > with new package versions as they see fit. > > Just give me the word, and I'd be happy to set up a server for you to > experiment with. Maybe I'm wrong but I think that we need firstly better package format. Now we are not able to create versioned packages for everything we need. -- Pavel |
Re: "slices" of packages (was: A process proposal for 3.10)
|
|
In reply to this post by Lex Spoon
For what its worth, I very much like the package universe approach for its conceptual simplicity.
Regards, Hernán On 17 Oct 2006 10:49:11 -0400,
Lex Spoon <[hidden email]> wrote: "Pavel Krivanek" <[hidden email]> writes: -- Saludos, Hernán |
|
|
In reply to this post by Lex Spoon
Lex Spoon wrote:
> "Pavel Krivanek" <[hidden email]> writes: > >> Very good notes. This problems are described in the thread with Stef's >> postmortem analysis >> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/109807.html) >> > > > It is just painful reading Stephane's description of package slices. > > Why not use Package Universes to organize a collection of package > versions? There would be a 3.10 release universe. The release team > would know the update password, and they could update that universe > with new package versions as they see fit. > > Just give me the word, and I'd be happy to set up a server for you to > experiment with. > > > -Lex > > > > > Karl |
Re: "slices" of packages (was: A process proposal for 3.10)
|
|
In reply to this post by Lex Spoon
On Oct 17, 2006, at 7:49 AM, Lex Spoon wrote: > "Pavel Krivanek" <[hidden email]> writes: >> Very good notes. This problems are described in the thread with >> Stef's >> postmortem analysis >> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- >> October/109807.html) > > > It is just painful reading Stephane's description of package slices. > > Why not use Package Universes to organize a collection of package > versions? There would be a 3.10 release universe. The release team > would know the update password, and they could update that universe > with new package versions as they see fit. First, let me say that I'm all in favour of Package Universes. I think every release of Squeak should really be about creating a base image for a universe of packages. However, I think there's been a bit of mis-understanding. "Slices" is the term I use in Monticello 2 for groups of program elements that define the contents of a snapshot. Like a package, a slice can produce a list of program elements, and answer questions about whether a given program element is included. Slices differ from packages in several ways, however. First, the definition of a slice is opaque, and there can be different kinds of slices. There are PackageSlices, for example, which simply include all the elements of the package, and ChangeSetSlices, which include all the elements in a ChangeSet. I haven't gotten around to writing any other kinds, but it's easy to imagine things like SendersSlices, which include all the senders of a particular selector, or PrefixSlices, which would all the classes with a particular prefix, or even RewriteToolSlices that do RB-style pattern matching. Second, slices are finer-grained than the packages we have now; they include variables separately from classes, and can thus extend classes with variables. Finally, slices can overlap. A given program element can be part of many different slices, and this doesn't interfere with proper versioning the way it does with Monticello 1. I think this last point is what Stéphane was talking about. Squeak 3.9 was the first release that tried to do everything in Monticello rather than using change sets. The big problem that came up was that most changes were spread across many packages. (This is hardly surprising, since the "packages" in the core image are pretty much arbitrary and have lots of entanglements and dependencies). This meant that any "update" would involve new versions of many packages, which would all have to be downloaded and merged. What used to take minutes now takes hours. A second problem is that Monticello 1 doesn't deal well with methods moving between packages, which is precisely what has to happen for the kernel to be disentangled. If the image were versioned using Monticello 2, these problems would disappear, since PackageSlices and ChangeSetSlices could be used side- by-side. Packages would become more and more independent over time, with change sets being used for cross-cutting changes, all the while maintaining version history and mergeability. Anyway, slices are not meant to compete with Package Universes; they solve a completely different problem. Colin |
|
|
In reply to this post by stephane ducasse-2
The main idea in the kind of process being suggested here is the value of decoupling the release process from the development process. You don't define the release in terms of what's in it, but rather in terms of how things get into it. How do you do that, when one feeds the other? The same way an airline decouples its flight schedules from the passenger's process of getting their bags packed and getting their butts to the airport. You set up the release process as a small set of gating dates, and a set of criteria for what can pass through that "boarding" gate. I.e. declare that there's a release on April 2. To be in it, the development must be complete on December 2, and it must have integrated and passed tests by February 2. (Just examples here.) All you know about that release now is that it might be different from the current one, if anything makes the dates, and that it -will- be released on April 2. Meanwhile, as a developer, if you want to contribute, you know exactly what needs to be done: the release process tells you how to get stuff into a release. That information is just those same gating dates and criteria. The criteria are usually about submission format, quality, and who gets to issue 'tickets' for things you'd like to submit; usually there are gatekeepers for the broad functional areas, and they work in the usual consensus ways. So as a developer you know what you need to do, by when, and you know that if you do it, then you'll get that change into the release. If you want to make something that can't be ready for this release, or if you just don't make it, then no problem. You try for the next one. The 'gating' criteria need to be clear and workable for both bug fixes and major surgery, so you usually express them in terms of stability; the usual form is that you'll take things if they don't cause regressions, and if the relevant gatekeeper(s) (whose allegiance is to a functional component, not the release process) recommends the change. This kind of process is usually called date-driven, or 'train'; it's different than a content-driven approach in that dates determine content, rather than the other way around. A lot of organizations have found it a good way to untangle the knots when managing large releases that have a lot of separately-developed moving parts; you let the subsystems (sometimes just one or two guys) run their own processes. If they pack your bags on time, and make it through security, they get on the flight. There is art in it. You have to manage the inflow and date staging so you don't flood the gating processes. But the focus there is on understanding the integration and testing and other "boarding" processes, not on predefining the content. Anyway, I just thought a rundown from that pure-process point of view might be helpful. It's not there isn't a place for setting vision and goals; it's just that those aren't part of this kind of a release process. They're part of the development processes, which are separate. - brad > I basically agree. > So in my proposal I was trying to see on what I want to work (based > on the artefacts already there and also what could > be vision) and see if other people are willing too. > Just making the list of things that should be integrated and > integrate them is a lot of time. > In general I would love to stop harvest fixes and produce more fun > stuff (but may be I'm a housekeeper that like to > clean stuff), may be I should stop because my job is different now. > > Stef > >> Hi Giovanni - >> >> I fully agree with the meta goals of your proposal, namely to >> enable people to do their own development and to limit the amount >> of time spend on each individual part of the release. >> >> That said, I'm in almost complete disagreement with the rest of >> your proposal ;-) The fundamental flaw in it is that you are >> trying to commit other people's time. Starting from "the board >> appoints a release team" (phase 0) over "the teams announce the >> development plans" (phase 1) and "code will get dropped" (phase 2) >> up until "the VMMaker team will want to..." (the example) you're >> happy committing other people's time. In my experience this has >> *always* been a fatal error in a volunteer open source project. >> >> The *only* time you can commit is your own. And given that, how >> much of your proposal works if the only time that you can count on >> is your own? Even if we want to change the release process we >> cannot change some fundamentals about the environment we're in. >> And one of those fundamentals is that (on a scale where it >> matters) you can't tell people what to do. They're doing it >> voluntarily, they're doing it for their own reasons and trying to >> change that simply won't work. To give a more concrete example, >> the maintenance work I do for FFI, Graphics, Balloon, and >> Compression packages is purely a volunteer effort. If you ask me >> about my "development plans" for the next six months, all I can >> say is "uhm ... ". Most importantly, because I have a fulltime job >> in a startup I for example couldn't possibly commit to a six >> months active development plan. It's simply not doable and even if >> it were I'd reject it on the grounds that unless you pay me for it >> I'm not going to treat this serious enough to make six month >> plans ;-) >> >> Both Stef and Markus understand that basic point. They both >> understand that in reality, all they can count on is their own >> time and they have reacted by investing more and more of their own >> time and effort in the process. And I would like us to change that >> process from one that leaves people burned out into one that can >> be done in a reasonable amount of time with a sustainable amount >> of energy. >> >> That change starts by admitting that we're all volunteers. Whether >> something will happen depends on so many factors that it's >> basically useless to try to do serious upfront planning for it. >> And again this is meant on scale - for each individual team it may >> make perfect sense but on scale I think you really can't. >> >> To emphasize that point even more I'll give you two recent >> examples: First, we have been talking for *years* about changing >> the source pointer in the methods. That it happens *now* is (from >> my point of view) exclusively due to the fact that we got a new >> sources file in 3.9 and lost the entire previous history for the >> single reason of the source limitations. Could anyone really have >> planned for that? I don't think so. Second, the SSL implementation >> we got recently. A while ago we started looking at SSL ourselves >> and decided to go with OpenSSL - we talked about Crypto team and >> their work but honestly, I would have called anyone a nut who >> would have told me that this stuff will be ready by now (I >> probably would have just laughed them out of the room). At least >> for me, this project came out of the blue, completely unforeseen >> and again nothing you could have possibly planned for. >> >> My point here is (in case you haven't guessed it by now) that in a >> volunteer community "planning" on the scale you are looking at is >> in many ways a futile exercise. Things happen for their own >> reasons at their own speed and not because you want them. And >> unless you want to put in endless amounts of energy by developing >> all the stuff that "your release" needs, you better find a way of >> dealing with that. >> >> Which brings me to the proposal I made earlier. The main goal of >> that proposal is really to get away from the upfront feature >> planning process and deal with the chaotic reality of open source >> development by *embracing* it. So instead of feature list of >> things that we SHOULD do, I'd like us to discuss things we HAVE >> done. Instead of wishful thinking I'd like us to talk about all >> the cool stuff that is actually happening! >> >> I think that this may be the only way to make sure we can survive >> the release process in a volunteer community like ours and it's >> surprisingly similar to what we did at SqC - the main difference >> is that SqC (instead of the community) picked which of the >> contributions got adopted and which ones didn't. At SqC (or any >> other commercial entity that I have been involved in) we have >> always been aware of error 33 and therefore never relied on the >> open source effort to produce specific results in a specific time >> frame. That's what companies do, that's why they take money to do >> it. However, anything that happened was always welcome and often a >> surprise. And I can say for sure that during those times nobody >> got burned out by the process. And I think that process can be >> recreated. >> >> Cheers, >> - Andreas >> >> Giovanni Corriga wrote: >>> Hi all, >>> since we've started discussing 3.10/4.0, I'd like to relay some >>> thoughts >>> that I've expressed some times ago on #squeak about a possible >>> development process for Squeak 3.10. >>> This proposal is based on two points: >>> - decentralization of development >>> - fixed duration of iterations ("timeboxing") >>> "Decentralization of development" means moving most of the >>> responsibility of development from the release team to the single >>> package mantainers (stewards). The release team should just be an >>> integrator of the code blessed by the stewards, and should >>> facilitate >>> coordination between the stewards of different packages. >>> "Timeboxing" means having a fixed length release cycle, at the >>> end of >>> which a new stable version is released. This means that if there are >>> some problems with a new feature, the deadline doesn't get >>> postponed; >>> instead it's the feature that gets dropped from the current >>> development >>> release and rescheduled for the next release. >>> How would this work? Here's a more detailed description. >>> -------------------------------------------------------------------- >>> --- >>> PHASE 0: RELEASE TEAM FORMATION >>> The SqF board will appoint a release team for 3.10. This team >>> will have >>> 3-7 members; 5 would be the sweet spot. >>> The first task for the release team will be to find a mantainer >>> for each >>> one of the packages currently in the image. If they can't find a >>> mantainer for a package, than said package _will get dropped from >>> the >>> image_ without any further discussion. >>> PHASE 1: RELEASE PLAN >>> After having found mantainers for every package, there's a package >>> selection phase, during which the team and the maintainers: >>> - decide which packages currently in the image should get removed >>> from >>> the image and turned into SqueakMap-loadable packages. >>> - decide which new packages can be added to the image or replace >>> other >>> packages currently in the image. >>> Input from the community and the stakeholders will be taken into >>> account. >>> After deciding which packages will be in the 3.10 image, the release >>> team, the mantainers and the community will work on creating the >>> release >>> plan. >>> Each package mantainer will announce what it plans to do for >>> 3.10. The >>> release team will integrate these proposals into a coherent release >>> plan, solving possible conflicts and coordination problems. The >>> community will be able to make comments and/or requests. >>> After all these steps, which shouldn't take more than a month, the >>> development of 3.10 can start. >>> PHASE 2: DEVELOPMENT >>> Development will have three stages: >>> - a 3 months alpha stage >>> - a 2 months beta stage >>> - a 1 month gamma/RC stage. >>> The deadline for each stage will be decided at the beginning of the >>> iteration. >>> Every week during each stage the release team will integrate the new >>> releases of each package blessed by the package mantainers. >>> Package mantainers will be the main responsible for development >>> of their >>> package and they'll be free to manage development as they like; >>> ideally >>> they should create a development team. >>> If at the end of the alpha stage some of the work items of the plan >>> aren't near completion, _these items and the corresponding code >>> will get >>> dropped_. If this is not possible, the code will be kept in the >>> image, >>> but it will have not to break the other code in the image. >>> During the beta and gamma stages, no new features will get added >>> to the >>> image; only bug fixes can go in. During the gamma stage, only >>> showstopper bugs will be fixed; other bug fixes (eg. cosmetical >>> fixes) >>> will be scheduled for 3.10.1. >>> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or >>> whatever) will get appointed and will work with the package >>> mantainers >>> to form the release plan for the next version. >>> EXAMPLE >>> Here's a an example of how things could possibly work. >>> Release plan: >>> During phase 1, the various package mantainers propose work >>> items. So >>> let's pretend that... >>> - VMMaker team will want to: >>> * integrate the async event patches useful for SqueakGtk. >>> * integrate the Ffenestri code in all VMs, including the Unix >>> one. >>> * work with the Kernel team/maintainer on CompiledMethod >>> cleanup. >>> - Nebraska team will work on removing it from the image. >>> - Pavel will want to work with various mantainers to integrate his >>> patches for his KernelImage system. >>> - Tools team will want to: >>> * better integrate AST and the Refactoring services. >>> * make Omnibrowser the default browser. >>> Now let's pretend that at the end of the alpha stage, the Tools team >>> still hasn't produced an Omnibrowser based debugger. Since it's >>> the end >>> of the alpha stage, the OBDebugger will be punted to the next >>> release, >>> and 3.10 will have a class browser based on OB but still the old >>> debugger. >>> -------------------------------------------------------------------- >>> --- >>> I believe a process such as the one I'm proposing can work and help >>> produce good quality releases. >>> I'd like to hear comments on this, even if they just say that my >>> proposal sucks. >>> Ciao, >>> Giovanni >> >> > > |
|
|
In reply to this post by Andreas.Raab
>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: A process proposal for 3.10 >Date: Mon, 16 Oct 2006 21:45:26 -0700 > >out of the room). At least for me, this project came out of the blue, >completely unforeseen and again nothing you could have possibly planned >for. > Me too. >Which brings me to the proposal I made earlier. The main goal of that >proposal is really to get away from the upfront feature planning process >and deal with the chaotic reality of open source development by *embracing* >it. So instead of feature list of things that we SHOULD do, I'd like us to >discuss things we HAVE done. Instead of wishful thinking I'd like us to >talk about all the cool stuff that is actually happening! > As usual, I agree with most everything you said. To this point I would say, while I do agree with most of it, I find it also good to have some kind of list of "wants" and "really should have's", so people with spare time can go see where they could make a big impact. |
|
|
In reply to this post by karl-8
>From: karl <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: A process proposal for 3.10 >Date: Tue, 17 Oct 2006 08:14:01 +0200 > >I agree with Andreas. But I think we should consider the possibility of the >community to pay for someone to do some of the dirty work, for example to >make the maintenance of the process easier. There have been people willing >to put up money for projects like this. We could identify what are the big >bottlenecks in the process and what can be done about them. Then we can >look for a reasonable solution and make a offer/bounty for a solution. >Karl > Maybe a good idea here would be to make a kind of "wish list" and let the comunity vote on it, so we can see what people value most. And people who vote also have the option of putting up bounty money. If everyone put in $5 or $10 dollars into something they really wanted, that could add up to enough cash to get some things fixed, maybe. And I'm sure someone is going to say "how do we decide who get's it?". Well how does mozilla do it? |
Re: A process proposal for 3.10
|
|
In reply to this post by Ramon Leon-4
> David T. Lewis wrote:
>> On Mon, Oct 16, 2006 at 09:45:26PM -0700, Andreas Raab wrote: >>> Which brings me to the proposal I made earlier. The main goal of >>> that proposal is really to get away from the upfront feature >>> planning process and deal with the chaotic reality of open source >>> development by *embracing* it. So instead of feature list of >>> things that we SHOULD do, I'd like us to discuss things we HAVE >>> done. Instead of wishful thinking I'd like us to talk about all >>> the cool stuff that is actually happening! >> +1 >> Dave > > +1 more, all that up front planning feels a lot like waterfall, > Smalltalker's most of all, should know better. It seems to me that your remark is not really in scope. If you look at 3.9 we set up a list of actions we wanted to have and we nearly did it. So.... |
Re: "slices" of packages (was: A process proposal for 3.10)
|
|
In reply to this post by Lex Spoon
On 17 oct. 06, at 16:49, Lex Spoon wrote: > "Pavel Krivanek" <[hidden email]> writes: >> Very good notes. This problems are described in the thread with >> Stef's >> postmortem analysis >> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- >> October/109807.html) > > > It is just painful reading Stephane's description of package slices. Sorry. Package universes are not the solution to the problem I described. At the end of the process of course you can get a number of package working in the context of an universe. Now in the process of getting a set of package working together you need to identify that package 1.5 is working with packageX 2.1 because you want to be able to rollback or to reload them together. This is why we had a script loader and kept all this information. Stef > > Why not use Package Universes to organize a collection of package > versions? There would be a 3.10 release universe. The release team > would know the update password, and they could update that universe > with new package versions as they see fit. > > Just give me the word, and I'd be happy to set up a server for you to > experiment with. > > > -Lex > > > |
Re: "slices" of packages (was: A process proposal for 3.10)
|
|
In reply to this post by Colin Putney
Tx colin
I thought that I was the only been so stupid that we get problems with changes in MC crosscutting several packages. > I think this last point is what Stéphane was talking about. Squeak > 3.9 was the first release that tried to do everything in > Monticello rather than using change sets. The big problem that came > up was that most changes were spread across many packages. (This is > hardly surprising, since the "packages" in the core image are > pretty much arbitrary and have lots of entanglements and > dependencies). Exact! > This meant that any "update" would involve new versions of many > packages, which would all have to be downloaded and merged. What > used to take minutes now takes hours. Not only we had to be able to identify all the packages introducing a change because something the changes would break. because of a load order or just a problem. I think that people should really try to do something a bit complex with MC that is not their nicely packaged application but a complex system like squeak to get the feel of the problem. Lot of problems showed up because squeak is not nicely packaged. Stef |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |