GNOME Bugzilla – Bug 665444
Update glib-2.0 VAPI and usage
Last modified: 2016-03-31 13:58:47 UTC
This is how it ended-up in upstream Vala repo.
Created attachment 202687 [details] [review] Update glib-2.0 VAPI and usage
Review of attachment 202687 [details] [review]: is that a copy of glib-2.0.vapi, if yes, can you try removing our local copy?
(In reply to comment #2) > Review of attachment 202687 [details] [review]: > > is that a copy of glib-2.0.vapi, Yes! > if yes, can you try removing our local copy? I thought you wanted to keep these as the work-around for not depending on unreleased vala?
(In reply to comment #3) > I thought you wanted to keep these as the work-around for not depending on > unreleased vala? No, my opinion has always been that I don't care if gnome-boxes depends on project-X.git. (Christophe is against that, he would "prefer" - I don't see how it's really possible - to only depend on released stuff. I think he said especially for compilers). I think we have to depend on spice-gtk, libvirt-glib, libosinfo (probably again gtk) etc.. from git, so why does it matter if we depend on vala from git. When releasing, lets be careful that all depedency also receive a release. So we should only do that with modules that follow gnome release calendar. That's not a problem, since they do. The local binding copy is only not to depend on something that vala didn't yet accepted, so we can move on until they make up their mind. Once it's in vala, the local copy should be removed.
(In reply to comment #4) > (In reply to comment #3) > > > I thought you wanted to keep these as the work-around for not depending on > > unreleased vala? > > No, my opinion has always been that I don't care if gnome-boxes depends on > project-X.git. (Christophe is against that, he would "prefer" - I don't see how > it's really possible - to only depend on released stuff. I think he said > especially for compilers). > > I think we have to depend on spice-gtk, libvirt-glib, libosinfo (probably again > gtk) etc.. from git, so why does it matter if we depend on vala from git. > > When releasing, lets be careful that all depedency also receive a release. So > we should only do that with modules that follow gnome release calendar. That's > not a problem, since they do. I'm OK with that. After a while I suspect all the APIs we need will be fixed anyways so we won't need to do this frequently for too long. > The local binding copy is only not to depend on something that vala didn't yet > accepted, so we can move on until they make up their mind. Once it's in vala, > the local copy should be removed. But that issue will be for every dep of ours. I don't think we need to do this cause juerg is usually pretty fast at getting patches in and since he's excited about Boxes using vala, I think he'll be even more quicker if we remember to mark the dep in bugzilla. :)
(In reply to comment #4) > (In reply to comment #3) > > > I thought you wanted to keep these as the work-around for not depending on > > unreleased vala? > > No, my opinion has always been that I don't care if gnome-boxes depends on > project-X.git. (Christophe is against that, he would "prefer" - I don't see how > it's really possible - to only depend on released stuff. I think he said > especially for compilers). Not exactly, I'm fine with using git for direct dependencies (libosinfo, libvirt-glib, spice-gtk), for other stuff we should avoid gratuitously breaking compat with stable released versions. Makes it easier to build the whole stack from scratch if you only need to compile a few self compiled module, we've got a safe fallback if one module gets a bad bug and then a feature we decided to rely on, ... Then you can also decide that you don't care and live in your nice glass castle, this just means you'll get less users/testers. And this is not just FUD, Lucas is one prime example of someone who would like to get involved but already has to overcome the hurdles caused by this "let's be cool kid and use the latest stuff" mentality.
Forgot to ask, if Linus merges this ubber cool virtualization feature, should we start mandating it right away? Sounds like we should because we can!
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > > > I thought you wanted to keep these as the work-around for not depending on > > > unreleased vala? > > > > No, my opinion has always been that I don't care if gnome-boxes depends on > > project-X.git. (Christophe is against that, he would "prefer" - I don't see how > > it's really possible - to only depend on released stuff. I think he said > > especially for compilers). > > Not exactly, I'm fine with using git for direct dependencies (libosinfo, > libvirt-glib, spice-gtk), How is vala not a "direct" dep? > for other stuff we should avoid gratuitously breaking > compat with stable released versions. Makes it easier to build the whole stack > from scratch if you only need to compile a few self compiled module, we've got > a safe fallback if one module gets a bad bug and then a feature we decided to > rely on, ... Then you can also decide that you don't care and live in your nice > glass castle, this just means you'll get less users/testers. This does not in any way affect users/testers for two reasons: 1. We will only be doing this for projects whose releases either follow gnome release cycle or we have good control over their releases (e.g libosinfo and libvirt-glib etc). i-e our release tarballs won't depend on unreleased stuff. 2. We don't depend on Vala at all in release tarballs (and therefore rpm or even rpm builds). > And this is not > just FUD, Lucas is one prime example of someone who would like to get involved > but already has to overcome the hurdles caused by this "let's be cool kid and > use the latest stuff" mentality. Its a new project and some of ours deps are also in their infancy so this is all good. Even if we don't require git, we still will be requiring the latest unstable releases of deps that are targeted for the same latest unstable version of gnome as Boxes' is targeting. So people like Lucas will still face the same problem since those releases won't be available in distros either.
(In reply to comment #8) > > Not exactly, I'm fine with using git for direct dependencies (libosinfo, > > libvirt-glib, spice-gtk), > > How is vala not a "direct" dep? > "direct" is probably not the right word, think "new" libraries whose boxes is one of the only users VS older dependencies already widely available and quite mature. > > This does not in any way affect users/testers for two reasons: I was talking about early adopters that want to track git with as less pain as possible... One more dep on something from git = pain++. One more dep on something from git for a module already installed on their system = even more pain/worries > 2. We don't depend on Vala at all in release tarballs (and therefore rpm or > even rpm builds). Yes, yes, obviously. That is, until they want to investigate a crash, fix a bug, ... > > > And this is not > > just FUD, Lucas is one prime example of someone who would like to get involved > > but already has to overcome the hurdles caused by this "let's be cool kid and > > use the latest stuff" mentality. > > Its a new project and some of ours deps are also in their infancy so this is > all good. I am *not* talking about deps which are in their infancy, I'm talking about stuff like vala or gtk+ > Even if we don't require git, we still will be requiring the latest > unstable releases of deps that are targeted for the same latest unstable > version of gnome as Boxes' is targeting. So people like Lucas will still face > the same problem since those releases won't be available in distros either. And imo, this is a bad idea to do that for no good reason. boxes *does* work with gtk 3.2 (from git unfortunately), so why force people to have glib 2.31 and gtk 3.3 for boxes? So far things seems to work fine with a stable vala, so why should we raise the dep just because we can? Just to make Lucas's life difficult?
(In reply to comment #9) > And imo, this is a bad idea to do that for no good reason. boxes *does* work > with gtk 3.2 (from git unfortunately), so why force people to have glib 2.31 > and gtk 3.3 for boxes? So far things seems to work fine with a stable vala, so > why should we raise the dep just because we can? Just to make Lucas's life > difficult? You are assuming that we have the time and energy to check against each release to find out which version exactly does Boxes work with. If you can assure us that Boxes works as well as with older gtk+, sure go ahead and reduce the dep. In short, nobody is talking about raising deps just for the fun of it but only when we need latest stuff. The point is not to 'be the cool kid' but to not to slow down development by caring about such non-issues.
(In reply to comment #10) > (In reply to comment #9) > > And imo, this is a bad idea to do that for no good reason. boxes *does* work > > with gtk 3.2 (from git unfortunately), so why force people to have glib 2.31 > > and gtk 3.3 for boxes? So far things seems to work fine with a stable vala, so > > why should we raise the dep just because we can? Just to make Lucas's life > > difficult? > > You are assuming that we have the time and energy to check against each release > to find out which version exactly does Boxes work with. I'm not asking you to do that... > If you can assure us > that Boxes works as well as with older gtk+, sure go ahead and reduce the dep. Yep, like in https://bugzilla.gnome.org/show_bug.cgi?id=664527#c7 where noone seemed to care ;) > > In short, nobody is talking about raising deps just for the fun of it but only > when we need latest stuff. The point is not to 'be the cool kid' but to not to > slow down development by caring about such non-issues. This bug seems to be about "we have what is needed in boxes not to require latest vala, but we'll drop that as soon as we can". So don't turn my comments into "you have to test every release of each of our dependencies before making any changes"
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > And imo, this is a bad idea to do that for no good reason. boxes *does* work > > > with gtk 3.2 (from git unfortunately), so why force people to have glib 2.31 > > > and gtk 3.3 for boxes? So far things seems to work fine with a stable vala, so > > > why should we raise the dep just because we can? Just to make Lucas's life > > > difficult? > > > > You are assuming that we have the time and energy to check against each release > > to find out which version exactly does Boxes work with. > > I'm not asking you to do that... > > > If you can assure us > > that Boxes works as well as with older gtk+, sure go ahead and reduce the dep. > > Yep, like in https://bugzilla.gnome.org/show_bug.cgi?id=664527#c7 where noone > seemed to care ;) I didn't ignore at least, that last comment is addressed directly to Marc-Andre AFAICT. Still, if you attach screenshot(s) of boxes running nicely it'll elevate our fear that Boxes don't look good when linked with older gtk+ and I can ack the change. > > In short, nobody is talking about raising deps just for the fun of it but only > > when we need latest stuff. The point is not to 'be the cool kid' but to not to > > slow down development by caring about such non-issues. > > This bug seems to be about "we have what is needed in boxes not to require > latest vala, but we'll drop that as soon as we can". So don't turn my comments > into "you have to test every release of each of our dependencies before making > any changes" What we have is a *work around* specifically for your satisfaction. :)
Attachment 202687 [details] pushed as 76cdf83 - Update glib-2.0 VAPI and usage