Re: [Sugar-devel] Sugar 0.88 packages
El Fri, 14-05-2010 a las 08:59 +0200, Tomeu Vizoso escribió: > I'm just asking for someone to propose a set of concrete and coherent > changes to the current process, is it really asking too much? > > I'm sorry but I cannot go through the old threads, ask individuals for > clarifications, then draft that new process myself. Do you want the proposal posted to the wiki? We could basically take Sasha's original plan and copy it to the wiki. I think it was quite well thought: http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023410.html I propose the following amendments: 1) Scrap the paragraph saying that any sugar developer can approve changes, because it turned out to be a controversial point. The "who" and the "where" of reviews are orthogonal topics that can be discussed independently. 2) Also scrap the part where Sascha proposes ways to track patches in the list, since we can now use Patchwork for this. 3) Add all the clarifications in my follow-up to Sascha's proposal: http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023468.html 4) The existing conventions still apply for referencing tickets in the commit logs 5) When a corresponding ticket exists, the committer should add a link to the patch discussion in Patchwork before committing the patch. Does this sound good enough for an initial iteration? If so, I could take care of transcribing it into the wiki. Then, we can further refine the process as we go. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
On Thu, May 13, 2010 at 22:07, Bernie Innocenti wrote: > El Thu, 13-05-2010 a las 20:23 +0200, Tomeu Vizoso escribió: > >> This implies that we are using the old process because nobody has come >> with a concrete proposal for changing it. AFAICS, the discussion has >> stalled because of lack of interest from its proponents. Once we agree >> on specific changes, the process docs in the wiki will be updated and >> it will come into effect. > > Ok, you're clearly in denial :-( > > >> And I'm supposed to track patches in the ml myself? I thought we >> wanted to reduce the load on the maintainers because we had few? > > All the maintainers have to do is reply with: > > Acked-by: name > > Then, the poster will commit the patch or find someone who will. You've > probably seen this happen a few times on sugar-devel too. > > In other projects, the maintainer is the only person who has commit > access to their tree, so they go ahead and merge the patch directly. > > > >> I have noticed that several of the patches that I have reviewed this >> week could have been approved by now if somebody would have >> pre-reviewed them. > > You're obviously disregarding the reviews done in the list. Almost every > patch posted was reviewed (either successfully or not). > > >> > iirc, you were opposed only to let any contributors approve patches for >> > Sugar modules with missing or unresponsive maintainers. >> >> I don't understand what you mean, can you rephrase? > > My initial proposal to unstuck the review process was to let any > existing Sugar contributor approve patches posted by others. > > You'll certainly remember this, because you commented that only those > who are able to appreciate the maintenance burden of a patch are to > decide on it. > > That's fine, as long as there are enough maintainers to review patches > in a reasonable amount of time. If this is not the case, we could tune > our requirements for becoming a maintainer so that we'll have more. > > There are many solutions to the problem of maintainer shortage, just > pick your favorite one. Except, maybe, halting development until the > planets come to the right alignment and maintainers of your liking start > to fall from the sky. > > >> How can you vote before you have a proposal? Or the proposal is "do >> whatever the linux kernel does"? > > Would you like me to open a bug in trac and attach the proposal to it so > you can review it? > > We've discussed the email-based review process once on IRC, in which you > agreed and asked to post the proposal to sugar-devel@, then a second > time on the thread following Sasha's summary. There was also a third > time, on the "Patchwork" thread. In all cases, you claimed to be in > favor for the general idea except for some minor points which I believe > have been addressed. > > Tomeu, please, let's not start over from the beginning. I'm just asking for someone to propose a set of concrete and coherent changes to the current process, is it really asking too much? I'm sorry but I cannot go through the old threads, ask individuals for clarifications, then draft that new process myself. Regards, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
El Thu, 13-05-2010 a las 20:23 +0200, Tomeu Vizoso escribió: > This implies that we are using the old process because nobody has come > with a concrete proposal for changing it. AFAICS, the discussion has > stalled because of lack of interest from its proponents. Once we agree > on specific changes, the process docs in the wiki will be updated and > it will come into effect. Ok, you're clearly in denial :-( > And I'm supposed to track patches in the ml myself? I thought we > wanted to reduce the load on the maintainers because we had few? All the maintainers have to do is reply with: Acked-by: name Then, the poster will commit the patch or find someone who will. You've probably seen this happen a few times on sugar-devel too. In other projects, the maintainer is the only person who has commit access to their tree, so they go ahead and merge the patch directly. > I have noticed that several of the patches that I have reviewed this > week could have been approved by now if somebody would have > pre-reviewed them. You're obviously disregarding the reviews done in the list. Almost every patch posted was reviewed (either successfully or not). > > iirc, you were opposed only to let any contributors approve patches for > > Sugar modules with missing or unresponsive maintainers. > > I don't understand what you mean, can you rephrase? My initial proposal to unstuck the review process was to let any existing Sugar contributor approve patches posted by others. You'll certainly remember this, because you commented that only those who are able to appreciate the maintenance burden of a patch are to decide on it. That's fine, as long as there are enough maintainers to review patches in a reasonable amount of time. If this is not the case, we could tune our requirements for becoming a maintainer so that we'll have more. There are many solutions to the problem of maintainer shortage, just pick your favorite one. Except, maybe, halting development until the planets come to the right alignment and maintainers of your liking start to fall from the sky. > How can you vote before you have a proposal? Or the proposal is "do > whatever the linux kernel does"? Would you like me to open a bug in trac and attach the proposal to it so you can review it? We've discussed the email-based review process once on IRC, in which you agreed and asked to post the proposal to sugar-devel@, then a second time on the thread following Sasha's summary. There was also a third time, on the "Patchwork" thread. In all cases, you claimed to be in favor for the general idea except for some minor points which I believe have been addressed. Tomeu, please, let's not start over from the beginning. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
On Thu, May 13, 2010 at 20:15, Bernie Innocenti wrote: > El Thu, 13-05-2010 a las 19:30 +0200, Tomeu Vizoso escribió: > >> Are your patches in this queue? >> >> http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=component&col=milestone&col=status&col=type&col=priority&milestone=!0.90&keywords=~r%3F >> >> If not, please read the code review process in the wiki and make sure >> you follow it. > > Does this imply that we're giving up on the new email-based review > process? Some maintainers have already adopted it and there seemed to be > general consensus on it, except maybe for some procedural details. This implies that we are using the old process because nobody has come with a concrete proposal for changing it. AFAICS, the discussion has stalled because of lack of interest from its proponents. Once we agree on specific changes, the process docs in the wiki will be updated and it will come into effect. >> Also, today I tried to review a patch of you in trac that had >> bitrotten because you hadn't updated it after review on the ml. Please >> make sure this doesn't happen by updating the attached patches or by >> pasting a link to the thread in archives. > > What's the ticket number? Have commented in the ticket, don't remember the number. >> There's quite a bit of things that non-maintainers can do to speed up >> this process, but unfortunately my last call for help was ignored. If >> people really care about this, please do reviews so that when the >> maintainer gets to it it can just make a quick read and set the flag >> to r+. It would also helped if submitters read the code guidelines in >> the first place, of course. > > Almost all the patches I've seen posted to the list where promptly > reviewed by one or multiple people. > > Please, don't ask contributors to also file a bug in Trac, attach the > patch and set the "r+" keyword before you can merge otherwise good > patches. And I'm supposed to track patches in the ml myself? I thought we wanted to reduce the load on the maintainers because we had few? >> Note that I'm still waiting for your replies to the comments on your >> post "[PATCH 1/2] This fixes part of >> http://bugs.sugarlabs.org/ticket/1876";. (And again, make sure that >> trac has a reference to the outcome of that review). > > I'll give it a look today. > > >> > Ideally, some of the existing contributors would step up and become >> > maintainers of specific modules or releases. I'm available to maintain >> > the 0.88 branch unless someone else wants to and I offered to become a >> > review peer for all the sugar-* modules. >> >> Thank you, that's a very generous offer. Why don't you start by >> pre-reviewing the patches in the queue so current maintainers see you >> have the required experience? That way you win twice: speed up the >> queue and become a maintainer yourself. > > Perhaps you haven't noticed that I'm *already* pre-reviewing plenty of > patches. Only, I do it on sugar-devel@, which is what we had agreed to > do a few weeks ago after discussing it extensively on IRC with you. I have noticed that several of the patches that I have reviewed this week could have been approved by now if somebody would have pre-reviewed them. > iirc, you were opposed only to let any contributors approve patches for > Sugar modules with missing or unresponsive maintainers. I don't understand what you mean, can you rephrase? > What shall we do to resolve the current uncertainty quickly? Shall we > vote the new review process with Selectricity? How can you vote before you have a proposal? Or the proposal is "do whatever the linux kernel does"? >> > BTW: I did some testing yesterday with F11-XO1-0.88 and results are very >> > encouraging. I'm seeing some issues related to font-size and window >> > borders. We need to figure out why these things work well in >> > sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading >> > Metacity, but it did not seem to help. >> >> Can you get some screenshots? (But please create a new thread) > > Ok, I'll do it when I announce the build. Maybe it will happen by this > weekend. Thanks, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
On Thu, May 13, 2010 at 18:47, Bernie Innocenti wrote: > El Wed, 12-05-2010 a las 14:24 -0300, Daniel Drake escribió: >> On 11 May 2010 20:23, Bernie Innocenti wrote: >> > Would you like me to go on and apply any relevant patches also to the >> > devel and F-13 branches in CVS? Let me know if you'd rather want me to >> > run each individual patch through you instead of committing them >> > directly. Either way is equally fast and easy on my side. >> >> Can't you do it properly by committing the patches and releasing new >> tarballs? >> No need to lock up the fixes. > > I'm posting all my patches to sugar-devel@, attaching them to tickets > and ping individual people on IRC. > > It's taking a lot of time because we have few active maintainers with > privileges to ack patches. Regarding releasing official tarballs, the > release manager position is currently vacant so don't expect them > anytime soon. And btw, I'm really puzzled at this. Maybe you need to search our wiki for "release manager" and check what it actually does? Regards, Tomeu > While we're working to fix our review process, it makes sense for > downstream projects on a tight schedule to apply obvious bugfix patches > directly to their packages. > > Ideally, some of the existing contributors would step up and become > maintainers of specific modules or releases. I'm available to maintain > the 0.88 branch unless someone else wants to and I offered to become a > review peer for all the sugar-* modules. > > BTW: I did some testing yesterday with F11-XO1-0.88 and results are very > encouraging. I'm seeing some issues related to font-size and window > borders. We need to figure out why these things work well in > sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading > Metacity, but it did not seem to help. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
El Thu, 13-05-2010 a las 19:30 +0200, Tomeu Vizoso escribió: > Are your patches in this queue? > > http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=component&col=milestone&col=status&col=type&col=priority&milestone=!0.90&keywords=~r%3F > > If not, please read the code review process in the wiki and make sure > you follow it. Does this imply that we're giving up on the new email-based review process? Some maintainers have already adopted it and there seemed to be general consensus on it, except maybe for some procedural details. > Also, today I tried to review a patch of you in trac that had > bitrotten because you hadn't updated it after review on the ml. Please > make sure this doesn't happen by updating the attached patches or by > pasting a link to the thread in archives. What's the ticket number? > There's quite a bit of things that non-maintainers can do to speed up > this process, but unfortunately my last call for help was ignored. If > people really care about this, please do reviews so that when the > maintainer gets to it it can just make a quick read and set the flag > to r+. It would also helped if submitters read the code guidelines in > the first place, of course. Almost all the patches I've seen posted to the list where promptly reviewed by one or multiple people. Please, don't ask contributors to also file a bug in Trac, attach the patch and set the "r+" keyword before you can merge otherwise good patches. > Note that I'm still waiting for your replies to the comments on your > post "[PATCH 1/2] This fixes part of > http://bugs.sugarlabs.org/ticket/1876";. (And again, make sure that > trac has a reference to the outcome of that review). I'll give it a look today. > > Ideally, some of the existing contributors would step up and become > > maintainers of specific modules or releases. I'm available to maintain > > the 0.88 branch unless someone else wants to and I offered to become a > > review peer for all the sugar-* modules. > > Thank you, that's a very generous offer. Why don't you start by > pre-reviewing the patches in the queue so current maintainers see you > have the required experience? That way you win twice: speed up the > queue and become a maintainer yourself. Perhaps you haven't noticed that I'm *already* pre-reviewing plenty of patches. Only, I do it on sugar-devel@, which is what we had agreed to do a few weeks ago after discussing it extensively on IRC with you. iirc, you were opposed only to let any contributors approve patches for Sugar modules with missing or unresponsive maintainers. What shall we do to resolve the current uncertainty quickly? Shall we vote the new review process with Selectricity? > > BTW: I did some testing yesterday with F11-XO1-0.88 and results are very > > encouraging. I'm seeing some issues related to font-size and window > > borders. We need to figure out why these things work well in > > sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading > > Metacity, but it did not seem to help. > > Can you get some screenshots? (But please create a new thread) Ok, I'll do it when I announce the build. Maybe it will happen by this weekend. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
On Thu, May 13, 2010 at 18:47, Bernie Innocenti wrote: > El Wed, 12-05-2010 a las 14:24 -0300, Daniel Drake escribió: >> On 11 May 2010 20:23, Bernie Innocenti wrote: >> > Would you like me to go on and apply any relevant patches also to the >> > devel and F-13 branches in CVS? Let me know if you'd rather want me to >> > run each individual patch through you instead of committing them >> > directly. Either way is equally fast and easy on my side. >> >> Can't you do it properly by committing the patches and releasing new >> tarballs? >> No need to lock up the fixes. > > I'm posting all my patches to sugar-devel@, attaching them to tickets > and ping individual people on IRC. Are your patches in this queue? http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=component&col=milestone&col=status&col=type&col=priority&milestone=!0.90&keywords=~r%3F If not, please read the code review process in the wiki and make sure you follow it. Also, today I tried to review a patch of you in trac that had bitrotten because you hadn't updated it after review on the ml. Please make sure this doesn't happen by updating the attached patches or by pasting a link to the thread in archives. > It's taking a lot of time because we have few active maintainers with > privileges to ack patches. Regarding releasing official tarballs, the > release manager position is currently vacant so don't expect them > anytime soon. There's quite a bit of things that non-maintainers can do to speed up this process, but unfortunately my last call for help was ignored. If people really care about this, please do reviews so that when the maintainer gets to it it can just make a quick read and set the flag to r+. It would also helped if submitters read the code guidelines in the first place, of course. Note that I'm still waiting for your replies to the comments on your post "[PATCH 1/2] This fixes part of http://bugs.sugarlabs.org/ticket/1876";. (And again, make sure that trac has a reference to the outcome of that review). > While we're working to fix our review process, it makes sense for > downstream projects on a tight schedule to apply obvious bugfix patches > directly to their packages. But in this case, there may be better alternatives. > Ideally, some of the existing contributors would step up and become > maintainers of specific modules or releases. I'm available to maintain > the 0.88 branch unless someone else wants to and I offered to become a > review peer for all the sugar-* modules. Thank you, that's a very generous offer. Why don't you start by pre-reviewing the patches in the queue so current maintainers see you have the required experience? That way you win twice: speed up the queue and become a maintainer yourself. > BTW: I did some testing yesterday with F11-XO1-0.88 and results are very > encouraging. I'm seeing some issues related to font-size and window > borders. We need to figure out why these things work well in > sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading > Metacity, but it did not seem to help. Can you get some screenshots? (But please create a new thread) Thanks, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
El Thu, 13-05-2010 a las 12:47 -0400, Bernie Innocenti escribió: > While we're working to fix our review process, it makes sense for > downstream projects on a tight schedule to apply obvious bugfix patches > directly to their packages. I forgot to mention that most my unmerged 0.84 patches are also available here for easy reference: http://people.sugarlabs.org/bernie/sugar/sugar-0.84-patches/ http://people.sugarlabs.org/bernie/sugar/sugar-artwork-0.84-patches/ http://people.sugarlabs.org/bernie/sugar/sugar-toolkit-0.84-patches/ Some of these patches also relevant to 0.88, but I have not started rebasing them yet. Meanwhile, experimental Sugar 0.88 packages for Fedora 11 can be obtained from this repo: http://repo.paraguayeduca.org/f11-xo1-py-sugar0.88/i386/os/ There are also OLPC OS images, but they're not yet in a publishable state. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.88 packages
El Wed, 12-05-2010 a las 14:24 -0300, Daniel Drake escribió: > On 11 May 2010 20:23, Bernie Innocenti wrote: > > Would you like me to go on and apply any relevant patches also to the > > devel and F-13 branches in CVS? Let me know if you'd rather want me to > > run each individual patch through you instead of committing them > > directly. Either way is equally fast and easy on my side. > > Can't you do it properly by committing the patches and releasing new tarballs? > No need to lock up the fixes. I'm posting all my patches to sugar-devel@, attaching them to tickets and ping individual people on IRC. It's taking a lot of time because we have few active maintainers with privileges to ack patches. Regarding releasing official tarballs, the release manager position is currently vacant so don't expect them anytime soon. While we're working to fix our review process, it makes sense for downstream projects on a tight schedule to apply obvious bugfix patches directly to their packages. Ideally, some of the existing contributors would step up and become maintainers of specific modules or releases. I'm available to maintain the 0.88 branch unless someone else wants to and I offered to become a review peer for all the sugar-* modules. BTW: I did some testing yesterday with F11-XO1-0.88 and results are very encouraging. I'm seeing some issues related to font-size and window borders. We need to figure out why these things work well in sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading Metacity, but it did not seem to help. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
