Re: [IAEP] [Sugar-devel] Proposal release management
On Thu, Jun 24, 2010 at 20:05, Michael Stone wrote: > Simon wrote: > >> What do others think about this? > > I'm glad that you have a proposal that excites Bernie, Bert, and Tomeu. > > I'm not sure what to think for myself because I don't know whether I > correctly understood your intent from my reading of your, Bernie's, > and Tomeu's words. (See below.) > > Bernie and Tomeu wrote: > >>> Regarding proposed patches, during our development cycle we have >>> collected a number of patches fixing bugs and adding small features. >> >> Just in case, note that the RM doesn't really care about what code >> goes in as long as features have been approved and we are in the right >> moment in the cycle (no freezes apply). > > Let's be clear: I want *nothing* to do with any software process that works > this way -- you've described a bad shell-script, not a release manager. First, the people who step forward to take roles such as this deserve all our consideration and gratitude. Supporting processes is a job with little glory but very important so the rest of us can keep doing our work. That said, if you can write a shell script that produces better release notes, please don't keep it for yourself. Second, you seem to be thinking of the RM role as it exists in downstream organizations. I suggest you to read about how releases are made in other organizations such as GNOME and Fedora, and try to understand how different they are. It makes sense because the inputs and the outputs are totally different, why both would have the same processes? I recommend that if you want so hard to be a RM that tells what changes go in and which not, that you offer your help to downstream projects such as OLPC, F11-XO1, SoaS, etc. Regards, Tomeu > However, I'm not sure that this description is actually what Simon was > talking about. Perhaps we should instead be talking about whatever role > describes the people who /do/ care about the code that goes in? > > Michael > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On 06/24/2010 11:49 AM, Bert Freudenberg wrote: > On 24.06.2010, at 09:32, Simon Schampijer wrote: > >> Hi, >> >> in May I tried to find someone to replace me as release manager [1] for >> 0.90, but as nobody has stepped up to do the job as we defined it I >> decided that it will be best to keep this role for some more time. I >> think it will be important for Sugar that we keep some continuation of >> the processes that we have been setting up during the last years. It >> would also be very good if someone would like to lend a hand with this >> or shadow me for future tasks so more people in Sugar Labs have direct >> hands-on knowledge. >> >> We defined the role of the release manager in the past 3 releases like >> the following: >> >> * setting the schedule >> * make sure that the Feature process is followed by the submitters [2] >> * keeping the wiki updated about the released modules and making sure to >> have final release notes available >> * sending email reminders about approaching Freezes, tarball due dates etc >> >> The schedule would be based on the GNOME releases, a 6 month release >> cycle. As there is not much time left for 0.90 [3] I think we should >> mainly focus on stabilizing and landing the features that were left over >> from the last release. I would start to announce a time frame for future >> releases so that future development can go on. New Features would be >> handled by the Feature process, as it has been the case in the past. >> >> What do others think about this? > > I think thanks are in order. It's a solid, low-risk plan for the "last mile" > in our development cycle. Now we just need to get our acts together in > covering the middle ground, so you actually have something to release :) > > To that extent I proposed to the Etoys developers to follow the Sugar > development cycle more closely. And that's what we're going to do. > > Thank you for stepping up again! > > - Bert - Hi Bert, awesome! Happy to hear that Etoys, a very important part of the Sugar experience, is rowing with us. I like the approach of Etoys to follow the Sugar release cycle. Similar to what Sugar does, we follow the GNOME cycle and they make sure that we are on track with the various distributions. Standing on the shoulders of giants... Regards, Simon ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On 06/24/2010 09:37 PM, Martin Langhoff wrote: > On Thu, Jun 24, 2010 at 2:05 PM, Michael Stone wrote: >> Perhaps we should instead be talking about whatever role >> describes the people who /do/ care about the code that goes in? > > Programmer. Implementor. Product manager. :-) > > I think the view is that features have their own "drivers" (motivated > programmers making sure it gets done) the RM keeps things orderly as > they get "merged" or "landed" into the master branch. > > The above is just my limited understanding -- proper SLers probably > know much better. > > cheers, > > > m Of course the release manager is interested in having a stable and releasable software at the end of the release cycle. So, he sets the freezing dates and makes sure that those are not violated. The actual code review happens by the module maintainers. They are responsible for the quality of their modules. And for accepting which feature goes in, we have the Feature process [1]. A defined process to make sure people are able to contribute their features in a fair manner. Btw, the basic idea has been adopted from the Feadora Feature process. The idea is: the responsibilities are distributed and handled by the persons with the expertise to do so. In short: the release manager gives a frame for the development cycle and makes sure people are able to contribute in different ways and that at the end of the cycle we have a software that is stable and fun to use. Nothing spectacular, but important to keep the ball rolling. Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On Thu, Jun 24, 2010 at 2:05 PM, Michael Stone wrote: > Perhaps we should instead be talking about whatever role > describes the people who /do/ care about the code that goes in? Programmer. Implementor. Product manager. :-) I think the view is that features have their own "drivers" (motivated programmers making sure it gets done) the RM keeps things orderly as they get "merged" or "landed" into the master branch. The above is just my limited understanding -- proper SLers probably know much better. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
Simon wrote: > What do others think about this? I'm glad that you have a proposal that excites Bernie, Bert, and Tomeu. I'm not sure what to think for myself because I don't know whether I correctly understood your intent from my reading of your, Bernie's, and Tomeu's words. (See below.) Bernie and Tomeu wrote: >> Regarding proposed patches, during our development cycle we have >> collected a number of patches fixing bugs and adding small features. > > Just in case, note that the RM doesn't really care about what code > goes in as long as features have been approved and we are in the right > moment in the cycle (no freezes apply). Let's be clear: I want *nothing* to do with any software process that works this way -- you've described a bad shell-script, not a release manager. However, I'm not sure that this description is actually what Simon was talking about. Perhaps we should instead be talking about whatever role describes the people who /do/ care about the code that goes in? Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On Thu, Jun 24, 2010 at 18:15, Bernie Innocenti wrote: > El Thu, 24-06-2010 a las 10:44 +0200, Tomeu Vizoso escribió: >> > What do others think about this? >> >> A big +1 from me, thanks a lot for taking this task once more, it is >> really important for Sugar. > > A big +1 from me too! Thank you, Simon! > > Regarding proposed patches, during our development cycle we have > collected a number of patches fixing bugs and adding small features. > > All of these patches have been tested on the XO-1 and XO-1.5, and many > should be upstreamable quality. Almost all patches have already appeared > on sugar-devel@, but it may be useful to post a comprehensive summary of > pending patches. Just in case, note that the RM doesn't really care about what code goes in as long as features have been approved and we are in the right moment in the cycle (no freezes apply). Regards, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
El Thu, 24-06-2010 a las 10:44 +0200, Tomeu Vizoso escribió: > > What do others think about this? > > A big +1 from me, thanks a lot for taking this task once more, it is > really important for Sugar. A big +1 from me too! Thank you, Simon! Regarding proposed patches, during our development cycle we have collected a number of patches fixing bugs and adding small features. All of these patches have been tested on the XO-1 and XO-1.5, and many should be upstreamable quality. Almost all patches have already appeared on sugar-devel@, but it may be useful to post a comprehensive summary of pending patches. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On Thu, Jun 24, 2010 at 4:49 AM, Bert Freudenberg wrote: > On 24.06.2010, at 09:32, Simon Schampijer wrote: > >> Hi, >> >> in May I tried to find someone to replace me as release manager [1] for >> 0.90, but as nobody has stepped up to do the job as we defined it I >> decided that it will be best to keep this role for some more time. I >> think it will be important for Sugar that we keep some continuation of >> the processes that we have been setting up during the last years. It >> would also be very good if someone would like to lend a hand with this >> or shadow me for future tasks so more people in Sugar Labs have direct >> hands-on knowledge. >> >> We defined the role of the release manager in the past 3 releases like >> the following: >> >> * setting the schedule >> * make sure that the Feature process is followed by the submitters [2] >> * keeping the wiki updated about the released modules and making sure to >> have final release notes available >> * sending email reminders about approaching Freezes, tarball due dates etc >> >> The schedule would be based on the GNOME releases, a 6 month release >> cycle. As there is not much time left for 0.90 [3] I think we should >> mainly focus on stabilizing and landing the features that were left over >> from the last release. I would start to announce a time frame for future >> releases so that future development can go on. New Features would be >> handled by the Feature process, as it has been the case in the past. >> >> What do others think about this? Thanks Simon. That is a good plan. You have been doing an outstanding job implementing it for the last several cycles. > I think thanks are in order. It's a solid, low-risk plan for the "last mile" > in our development cycle. Now we just need to get our acts together in > covering the middle ground, so you actually have something to release :) > > To that extent I proposed to the Etoys developers to follow the Sugar > development cycle more closely. And that's what we're going to do. Thanks Bert. That will help those of us working downstream a great deal. As a side note, what is the situation with Etoys vs scratch? Many teachers are very familiar with (and love) scratch and wonder why sugar ships Etoys:-( david > Thank you for stepping up again! > > - Bert - > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
On 24.06.2010, at 09:32, Simon Schampijer wrote: > Hi, > > in May I tried to find someone to replace me as release manager [1] for > 0.90, but as nobody has stepped up to do the job as we defined it I > decided that it will be best to keep this role for some more time. I > think it will be important for Sugar that we keep some continuation of > the processes that we have been setting up during the last years. It > would also be very good if someone would like to lend a hand with this > or shadow me for future tasks so more people in Sugar Labs have direct > hands-on knowledge. > > We defined the role of the release manager in the past 3 releases like > the following: > > * setting the schedule > * make sure that the Feature process is followed by the submitters [2] > * keeping the wiki updated about the released modules and making sure to > have final release notes available > * sending email reminders about approaching Freezes, tarball due dates etc > > The schedule would be based on the GNOME releases, a 6 month release > cycle. As there is not much time left for 0.90 [3] I think we should > mainly focus on stabilizing and landing the features that were left over > from the last release. I would start to announce a time frame for future > releases so that future development can go on. New Features would be > handled by the Feature process, as it has been the case in the past. > > What do others think about this? I think thanks are in order. It's a solid, low-risk plan for the "last mile" in our development cycle. Now we just need to get our acts together in covering the middle ground, so you actually have something to release :) To that extent I proposed to the Etoys developers to follow the Sugar development cycle more closely. And that's what we're going to do. Thank you for stepping up again! - Bert - ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
