[opensuse-edu] Update Sugar packages
Hi all, A while back I updated Sugar packages (Glucose and Fructose) to latest version (0.96), it is hosted at my home project on OBS [1]. I have did some test, and now I would like to merge changes back into X11:Sugar. Because 0.96 partially require GTK 3.0, it seems unlikely to support 11.4, even support for 12.1 will need many effort. I tend to only build 0.96 for 12.2 and Factory. I'm not sure which project should I submit merging request to, X11:Sugar [2] or X11:Sugar:Unstable [3]? What else I need to pay attention to? Thanks, [1] https://build.opensuse.org/project/show?project=home%3Adramwang%3Asugar [2] https://build.opensuse.org/project/show?project=X11%3ASugar [3] https://build.opensuse.org/project/show?project=X11%3ASugar%3AUnstable -- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Fri, Aug 17, 2012 at 5:56 PM, Xin Wang <dram.wang@gmail.com> wrote:
Hi all,
A while back I updated Sugar packages (Glucose and Fructose) to latest version (0.96), it is hosted at my home project on OBS [1].
I have did some test, and now I would like to merge changes back into X11:Sugar.
Because 0.96 partially require GTK 3.0, it seems unlikely to support 11.4, even support for 12.1 will need many effort. I tend to only build 0.96 for 12.2 and Factory.
I'm not sure which project should I submit merging request to, X11:Sugar [2] or X11:Sugar:Unstable [3]?
What else I need to pay attention to?
Hi Xin I've added you and litekok as maintainers to both Sugar projects, you are also a bugowner as no one else is working on sugar packages on openSUSE at the moment. Let me know the status of packages, if the entire sugar stack is complete and usable, if so then we may include it again in openSUSE Edu Li-f-e media.
Thanks,
Thank you for your contribution -J
[1] https://build.opensuse.org/project/show?project=home%3Adramwang%3Asugar [2] https://build.opensuse.org/project/show?project=X11%3ASugar [3] https://build.opensuse.org/project/show?project=X11%3ASugar%3AUnstable
-- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/17 Jigish Gohil <cyberorg@opensuse.org>:
On Fri, Aug 17, 2012 at 5:56 PM, Xin Wang <dram.wang@gmail.com> wrote:
Hi all,
A while back I updated Sugar packages (Glucose and Fructose) to latest version (0.96), it is hosted at my home project on OBS [1].
I have did some test, and now I would like to merge changes back into X11:Sugar.
Because 0.96 partially require GTK 3.0, it seems unlikely to support 11.4, even support for 12.1 will need many effort. I tend to only build 0.96 for 12.2 and Factory.
I'm not sure which project should I submit merging request to, X11:Sugar [2] or X11:Sugar:Unstable [3]?
What else I need to pay attention to?
Hi Xin
I've added you and litekok as maintainers to both Sugar projects, you are also a bugowner as no one else is working on sugar packages on openSUSE at the moment.
OK, thanks.
Let me know the status of packages, if the entire sugar stack is complete and usable, if so then we may include it again in openSUSE Edu Li-f-e media.
It's great if Sugar can be included in Edu Li-f-e. If new Edu Li-f-e is based on 12.2, I'll focus on 12.2 firstly. I have updated Glucose and Fructose part of Sugar, those packages are quite usable, though some more tests is needed. For now, only known bug is Etoys failed to run in X86_64 platform, I'll try to fix it. When does new version of Edu Li-f-e scheduled to release? If time allows, I'll try to update other activity packages in X11:Sugar.
Thanks,
Thank you for your contribution
-J
[1] https://build.opensuse.org/project/show?project=home%3Adramwang%3Asugar [2] https://build.opensuse.org/project/show?project=X11%3ASugar [3] https://build.opensuse.org/project/show?project=X11%3ASugar%3AUnstable
-- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Fri, Aug 17, 2012 at 8:25 PM, Xin Wang <dram.wang@gmail.com> wrote:
2012/8/17 Jigish Gohil <cyberorg@opensuse.org>:
On Fri, Aug 17, 2012 at 5:56 PM, Xin Wang <dram.wang@gmail.com> wrote:
Let me know the status of packages, if the entire sugar stack is complete and usable, if so then we may include it again in openSUSE Edu Li-f-e media.
It's great if Sugar can be included in Edu Li-f-e.
If new Edu Li-f-e is based on 12.2, I'll focus on 12.2 firstly.
It will be based on openSUSE 12.2.
I have updated Glucose and Fructose part of Sugar, those packages are quite usable, though some more tests is needed. For now, only known bug is Etoys failed to run in X86_64 platform, I'll try to fix it.
When does new version of Edu Li-f-e scheduled to release? If time allows, I'll try to update other activity packages in X11:Sugar.
Aim is to release as soon as official 12.2 is out, lets see how 12.2 turns out, if there are no major bugs then soon otherwise we wait for few online updates fixes before we release openSUSE Edu. Cheers -J -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/18 Jigish Gohil <cyberorg@opensuse.org>:
On Fri, Aug 17, 2012 at 8:25 PM, Xin Wang <dram.wang@gmail.com> wrote:
2012/8/17 Jigish Gohil <cyberorg@opensuse.org>:
On Fri, Aug 17, 2012 at 5:56 PM, Xin Wang <dram.wang@gmail.com> wrote:
Let me know the status of packages, if the entire sugar stack is complete and usable, if so then we may include it again in openSUSE Edu Li-f-e media.
It's great if Sugar can be included in Edu Li-f-e.
If new Edu Li-f-e is based on 12.2, I'll focus on 12.2 firstly.
It will be based on openSUSE 12.2.
I have updated Glucose and Fructose part of Sugar, those packages are quite usable, though some more tests is needed. For now, only known bug is Etoys failed to run in X86_64 platform, I'll try to fix it.
When does new version of Edu Li-f-e scheduled to release? If time allows, I'll try to update other activity packages in X11:Sugar.
Aim is to release as soon as official 12.2 is out, lets see how 12.2 turns out, if there are no major bugs then soon otherwise we wait for few online updates fixes before we release openSUSE Edu.
Cheers
-J
OK. Because 11.4 will reach its end of life soon, I'd like to disable build for 11.4 by now, so that packages for 11.4 will not affected by updates. In other words, we will only support 12.2, Factory, and partially 12.1 for future updates. Is it OK to do that? -- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Sat, Aug 18, 2012 at 1:11 PM, Xin Wang <dram.wang@gmail.com> wrote:
Aim is to release as soon as official 12.2 is out, lets see how 12.2 turns out, if there are no major bugs then soon otherwise we wait for few online updates fixes before we release openSUSE Edu.
Because 11.4 will reach its end of life soon, I'd like to disable build for 11.4 by now, so that packages for 11.4 will not affected by updates.
In other words, we will only support 12.2, Factory, and partially 12.1 for future updates. Is it OK to do that?
Yes, you can concentrate on 12.2 first to get everything working properly, Factory and other versions can be low priority, Factory will again be priority as next openSUSE version hits Beta. Cheers -J -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/18 Jigish Gohil <cyberorg@opensuse.org>:
On Sat, Aug 18, 2012 at 1:11 PM, Xin Wang <dram.wang@gmail.com> wrote:
Aim is to release as soon as official 12.2 is out, lets see how 12.2 turns out, if there are no major bugs then soon otherwise we wait for few online updates fixes before we release openSUSE Edu.
Because 11.4 will reach its end of life soon, I'd like to disable build for 11.4 by now, so that packages for 11.4 will not affected by updates.
In other words, we will only support 12.2, Factory, and partially 12.1 for future updates. Is it OK to do that?
Yes, you can concentrate on 12.2 first to get everything working properly, Factory and other versions can be low priority, Factory will again be priority as next openSUSE version hits Beta.
Cheers
-J
OK, I get it. -- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Sat, Aug 18, 2012 at 1:19 PM, Xin Wang <dram.wang@gmail.com> wrote:
OK, I get it.
BTW, we have IRC Freenode #opensuse-edu channel, were alsroot, previous maintainer of Sugar package on openSUSE and Sugar developer is always lurking, you can join in too. Ciao -J -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/18 Jigish Gohil <cyberorg@opensuse.org>:
On Sat, Aug 18, 2012 at 1:19 PM, Xin Wang <dram.wang@gmail.com> wrote:
OK, I get it.
BTW, we have IRC Freenode #opensuse-edu channel, were alsroot, previous maintainer of Sugar package on openSUSE and Sugar developer is always lurking, you can join in too.
Ciao
-J
Thanks, I have contacted him before. Surely, there will be some problems need to consult him.. :) -- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
Hi On Sat, 18 Aug 2012 15:41:23 +0800 Xin Wang wrote:
Because 11.4 will reach its end of life soon, I'd like to disable build for 11.4 by now, so that packages for 11.4 will not affected by updates.
Jip: we do the same for old releases (means: the OBS repo is in a "build disabled" state). So users who have added the repo to their list would only get new packages once some packager enabled build for that repository explizitely. That is the fact in Education for 11.4 already - and I like to do it also for 12.1 and maybe even 12.2 once 12.2 is released (objections?). That way, packagers can concentrate on the upcoming release and just need to touch a package for old releases once a user requests an update or the packager wants to maintain it for old releases. That would drastically reduce the "refresh time" of the Education repo for endusers as the repo metadata will only change if an important update is released for their distribution.
In other words, we will only support 12.2, Factory, and partially 12.1 for future updates. Is it OK to do that?
Absolutely. ...and thanks a lot for your work on those packages! With kind regards, Lars -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/20 Lars Vogdt <lrupp@suse.de>:
Hi
On Sat, 18 Aug 2012 15:41:23 +0800 Xin Wang wrote:
Because 11.4 will reach its end of life soon, I'd like to disable build for 11.4 by now, so that packages for 11.4 will not affected by updates.
Jip: we do the same for old releases (means: the OBS repo is in a "build disabled" state). So users who have added the repo to their list would only get new packages once some packager enabled build for that repository explizitely.
That is the fact in Education for 11.4 already - and I like to do it also for 12.1 and maybe even 12.2 once 12.2 is released (objections?).
That way, packagers can concentrate on the upcoming release and just need to touch a package for old releases once a user requests an update or the packager wants to maintain it for old releases.
That would drastically reduce the "refresh time" of the Education repo for endusers as the repo metadata will only change if an important update is released for their distribution.
What about branching a subproject based on each Education release? That way further development will not affect it, and we can easily apply patches in that branch when some bug is encountered.
In other words, we will only support 12.2, Factory, and partially 12.1 for future updates. Is it OK to do that?
Absolutely. ...and thanks a lot for your work on those packages!
My pleasure. :)
With kind regards, Lars
-- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Di 21 Aug 2012 00:31:10 CEST Xin Wang <dram.wang@gmail.com> wrote:
Jip: we do the same for old releases (means: the OBS repo is in a "build disabled" state). So users who have added the repo to their list would only get new packages once some packager enabled build for that repository explizitely.
That is the fact in Education for 11.4 already - and I like to do it also for 12.1 and maybe even 12.2 once 12.2 is released (objections?).
That way, packagers can concentrate on the upcoming release and just need to touch a package for old releases once a user requests an update or the packager wants to maintain it for old releases.
That would drastically reduce the "refresh time" of the Education repo for endusers as the repo metadata will only change if an important update is released for their distribution.
What about branching a subproject based on each Education release? That way further development will not affect it, and we can easily apply patches in that branch when some bug is encountered.
Well, this was not necessary until now. I'm just aware of a handful packages (from > 400) that were reported via Bugzilla and needed a fix for an old release. Patching them and re-enabling build in the Education project itself was much easier than providing a branch of the whole Education project. Further development was also not affected as those packages were broken on younger releases, too. But I won't prevent a branch if someone else really likes it - I'm just curious what would be better than now for the Education project: currently nobody has to take care of any branch or sub-project. Everything is in the plain Education project and development takes also place there: just for the upcoming releases only. With kind regards, Lars -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/21 Lars Vogdt <lrupp@suse.de>:
On Di 21 Aug 2012 00:31:10 CEST Xin Wang <dram.wang@gmail.com> wrote:
Jip: we do the same for old releases (means: the OBS repo is in a "build disabled" state). So users who have added the repo to their list would only get new packages once some packager enabled build for that repository explizitely.
That is the fact in Education for 11.4 already - and I like to do it also for 12.1 and maybe even 12.2 once 12.2 is released (objections?).
That way, packagers can concentrate on the upcoming release and just need to touch a package for old releases once a user requests an update or the packager wants to maintain it for old releases.
That would drastically reduce the "refresh time" of the Education repo for endusers as the repo metadata will only change if an important update is released for their distribution.
What about branching a subproject based on each Education release? That way further development will not affect it, and we can easily apply patches in that branch when some bug is encountered.
Well, this was not necessary until now. I'm just aware of a handful packages (from > 400) that were reported via Bugzilla and needed a fix for an old release. Patching them and re-enabling build in the Education project itself was much easier than providing a branch of the whole Education project. Further development was also not affected as those packages were broken on younger releases, too.
I see. If I got it right, active development period of Education release begins near new openSUSE release, so there will be little conflict between maintenance time of old one and development time of the new. When a new version is released, old one will be obsoleted soon. is that right?
But I won't prevent a branch if someone else really likes it - I'm just curious what would be better than now for the Education project: currently nobody has to take care of any branch or sub-project. Everything is in the plain Education project and development takes also place there: just for the upcoming releases only.
With kind regards, Lars
-- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
On Di 21 Aug 2012 08:34:16 CEST Xin Wang <dram.wang@gmail.com> wrote:
Well, this was not necessary until now. I'm just aware of a handful packages (from > 400) that were reported via Bugzilla and needed a fix for an old release. Patching them and re-enabling build in the Education project itself was much easier than providing a branch of the whole Education project. Further development was also not affected as those packages were broken on younger releases, too.
I see.
If I got it right, active development period of Education release begins near new openSUSE release, so there will be little conflict between maintenance time of old one and development time of the new.
Yes, right.
When a new version is released, old one will be obsoleted soon.
is that right?
The old packages simply stay in the old repositories (for the old distributions) if someone just disables them in the OBS. For the enduser of this distribution it simply looks like there are no more package updates. The old version will just be obsoleted if a) there's a bug report against that old package or b) the packager himself decides to release an update for the old distribution. With kind regards, Lars -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
2012/8/21 Lars Vogdt <lrupp@suse.de>:
On Di 21 Aug 2012 08:34:16 CEST Xin Wang <dram.wang@gmail.com> wrote:
Well, this was not necessary until now. I'm just aware of a handful packages (from > 400) that were reported via Bugzilla and needed a fix for an old release. Patching them and re-enabling build in the Education project itself was much easier than providing a branch of the whole Education project. Further development was also not affected as those packages were broken on younger releases, too.
I see.
If I got it right, active development period of Education release begins near new openSUSE release, so there will be little conflict between maintenance time of old one and development time of the new.
Yes, right.
When a new version is released, old one will be obsoleted soon.
is that right?
The old packages simply stay in the old repositories (for the old distributions) if someone just disables them in the OBS. For the enduser of this distribution it simply looks like there are no more package updates.
The old version will just be obsoleted if a) there's a bug report against that old package or b) the packager himself decides to release an update for the old distribution.
OK, I get it.
With kind regards, Lars
-- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-edu+owner@opensuse.org
participants (3)
-
Jigish Gohil -
Lars Vogdt -
Xin Wang