Re: dockapps.git repo redesign question
On Fri, 05 Apr 2013, Carlos R. Mafra escribió: On Fri, 5 Apr 2013 at 12:20:28 +0200, BALATON Zoltan wrote: There were patches to wmbiff recently. What should I do? Write a patch changing the #define version x.y for wmbiff only and announcing that I'm releasing a new wmbiff? Or just tag the repository with a tag wmbiff-x.y when finished merging all the patches and changed the #define in wmbiff to a new version. That's what we can call a release: some marked point in the repo which can be identified with a version number. Ok. I can do that and will do that if that would help how distros want to do things. I am not sure about how to do it for Debian. I need read some documents about git + tags + versions. [snip] But as I said I don't use the dockapps repo, so it's only a proposal and you are free to decide how you do your work and packagers can also say if they like this proposal or not. I just though this might be an acceptable compromise for both parties. I'd like to have some kind of confirmation from packagers that this could have a chance to work. I hope I'm not making things more difficult than they already are, dockapps.git was meant to simplify things. I think we should remember a bit what happened [1]. We created a repo to pull the orphaned dockapps, and have all together, but IMO because that was better for us, (as upstream developers). But, probably that idea was not the best for packagers (for example, the debian/watch file cannot be used to test new versions). I will check if is possible use tags for debian/watch. http://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg00277.html -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Fri, 5 Apr 2013 at 12:20:28 +0200, BALATON Zoltan wrote: There were patches to wmbiff recently. What should I do? Write a patch changing the #define version x.y for wmbiff only and announcing that I'm releasing a new wmbiff? Or just tag the repository with a tag wmbiff-x.y when finished merging all the patches and changed the #define in wmbiff to a new version. That's what we can call a release: some marked point in the repo which can be identified with a version number. Ok. I can do that and will do that if that would help how distros want to do things. Let's say today I tag the dockapps.git repo as wmbiff-2.0, how would that help someone? I think it would help Alexey or Kix to know that they should update the wmbiff package in their distros and (reproducibly) can get a revision from the repository that contains exactly version 2.0 of wmbiff. If the next day some patches to wmvolman are merged and tagged with wmvolman-1.15 they know that they only have to update the wmvolman package and can again get the corresponding revision from the repo. So even if the tarball from the repo contains all the dockapps they are still versioned separately and one can use them both together or separately as they wish. The administrative overhead may be a bit higher but not much: instead of just using tags like dockapps-3.0, dockapps-3.1, etc. you would use tags for independent apps but the work involved is the same (merge patches, tag repo). I had the impression Alexey wanted more than that because of the separate tarball being uploaded somewhere story. But if all people want is some kind of notification: Look, wmbiff changed recently and there's a new version x.y for it. The repo has its directory along with others, deal with that. and having the dockapps.git tag playing the role of a notifier, then that's also fine. But as I said I don't use the dockapps repo, so it's only a proposal and you are free to decide how you do your work and packagers can also say if they like this proposal or not. I just though this might be an acceptable compromise for both parties. I'd like to have some kind of confirmation from packagers that this could have a chance to work. I hope I'm not making things more difficult than they already are, dockapps.git was meant to simplify things. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Thu, 4 Apr 2013 at 8:07:34 +, Rodolfo García Peñas (kix) wrote: Quoting Rodolfo García Peñas (kix) k...@kix.es: Perhaps Carlos, Alexey, both can be uploaders for the dockapps, in repo.or.cz or github. But, IMO, we need something like drupal, with BTS,... all together. Perhaps is not bad Idea move to github. Github has these things (bts,...) [1] We can try it with dockapps. Ok, we can try that and I could move from repo.or.cz. The question is whether Alexey wants to be the maintainer of dockapps and I decommission the dockapps.git and my maintainance of it. I'd rather save Alexey's time for his work in wdm -- which I anxiously keep 'git pull'ing waiting for updates which would make it work here :-), but I'm ok either way. The only strong opinion I have on this issue is to have all those dockapps in one repo. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On 04.04.2013 10:43, Carlos R. Mafra wrote: [snip] The only strong opinion I have on this issue is to have all those dockapps in one repo. I don't know git that well, but I thought there were submodules. So we can have one repo for each dockapp and one repo which contains only a shell that has all dockapps as submodule. Would that work? Best regards Andreas -- (`-''-/).___..--''`-._ `o_ o ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' .' (il).-'' (li).' ((!.-' Andreas Tscharner a...@vis.ethz.ch ICQ-No. 14356454 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Thu, 4 Apr 2013, Carlos R. Mafra wrote: There _is_ a huge advantage in keeping things together and releasing them together. Depending on how you look at it. It may be less work for you but for users who only use one or two dockapps (which is typical) from the 40 you plan to release together means overhead and unecessary updates for unrelated changes in dockapps they don't even use. Same for packagers who might not even be the same person for all the included dockapps so distros should change their ways too. So it's not clear that this is an advantage for everyone. We should do the same here. These dockapps were mostly dead tarballs hidden somewhere, no maintainer no nothing. Why do we have to care about historic version numbers for them? It's time to move on and change. Let's refer to them as v3.0 collectively, it's much simpler. It's not about historic version numbers but trying to put unrelated things into one package which seems wrong. I tag the repo v3.0 and that's it. If wmbiff changes and no other dockapp changes, who cares if all of them become v3.1 one year later? It's the repo that's moving, not the individual dockapps. Yes but look at it from the users' point of view. Do they want to install all dockapps to only use wmnet? Do they care about changes in other dockapps and see updates for dockapps package while wmnet is still the same even if dockapps version has changed from 3.0 to 3.24? The problem happens when people consider the dockapps there individually and want to keep track of them individually. But this naturally happens. The dockapps are individual, they are developed individually (people only use a few and only care about those, submit patches for those). The only thing that holds them together is the common repo and nothing else. These are less related codes than drivers in your example because the drivers are all closely related to the kernel but dockapps are not related to each other nor really to Window Maker as other window managers support dockapps too. They're just put together in a repo trying to lower administrative overhead but this does not make them related. If you do that, it doesn't make sense to have them all in one repository in the first place and the difficulties pointed in this thread are related to trying to solve the wrong problem. And when you have the wrong problem to solve, no matter what you do it won't be the correct solution. Could there be a middle ground where we can have the advantages of both? Like keeping them in one repo but using separate version numbers and releasing them separately (either by tagging them separately or creating tarballs for release versions and putting them somewhere official)? I think this is what was proposed. What's your opinion on this? Yes, I agree with you. The solution is to treat them together or split them into 40 different repos. Or somewhere inbetween... I think the kernel viewpoint makes sense because it makes things simpler to manage. But it requires a small change in our mindset. IMO apart from the driver analogy does not really apply here it also may require a bit bigger change in distros' workflow so it does not make things easier for everyone. The other solution is to split the repo. But in this case I don't want to be the maintainer of 40 different repos, that's too much for me. How about keeping the common repo to make your job easier but keeping the tags and version numbers different for dockaps so unrelated changes don't cause updates for everyone. If git cannot tag individual directories we might adopt a convention like using tags like wmnet-1.1 wmbiff-2.0 etc. on the common repo so if someone wants to fetch a specific version of one dockapp would still be able to do that but tags are updated individually when the corresponding apps change. This way it would be a common repo and not 40 different ones but distros could choose to package dockapps separately. This seems to be the best for everyone and only a little more work because then you don't have to manage the release tarballs either. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Thu, 4 Apr 2013 at 22:51:26 +0200, BALATON Zoltan wrote: On Thu, 4 Apr 2013, Carlos R. Mafra wrote: There _is_ a huge advantage in keeping things together and releasing them together. Depending on how you look at it. It may be less work for you but for users who only use one or two dockapps (which is typical) from the 40 you plan to release together means overhead and unecessary updates for unrelated changes in dockapps they don't even use. But that is not new behavior. I use ksnapshot and to have that app I need to install the 'graphics' package and then I also have okular etc (or something like that). Same for packagers who might not even be the same person for all the included dockapps so distros should change their ways too. So it's not clear that this is an advantage for everyone. Right, I agree that my idea would require adjustments in distros. Your point about different packagers for different dockapps is true. One could see this as good, now only one guy manages all of them and free the others to do other stuff, or let's not change how things are working for many years. I simply don't know. It's a pity that dockapps.git is causing troubles. I tag the repo v3.0 and that's it. If wmbiff changes and no other dockapp changes, who cares if all of them become v3.1 one year later? It's the repo that's moving, not the individual dockapps. Yes but look at it from the users' point of view. Do they want to install all dockapps to only use wmnet? Do they care about changes in other dockapps and see updates for dockapps package while wmnet is still the same even if dockapps version has changed from 3.0 to 3.24? This is not ideal, but this is not unheard of either for other applications. The other example I have is with texlive. They have so many packages that it makes sense to bundle a lot of them together. But one day I found a regression with Tikz in plain TeX, and then I needed to downgrade the whole texlive 2012 to 2011 because there was no granularity in downgrading only tikz. So that happens already, I'm not proposing something which others have not considered to be a solution for their problems. The problem happens when people consider the dockapps there individually and want to keep track of them individually. But this naturally happens. The dockapps are individual, they are developed individually (people only use a few and only care about those, submit patches for those). The only thing that holds them together is the common repo and nothing else. These are less related codes than drivers in your example because the drivers are all closely related to the kernel but dockapps are not related to each other nor really to Window Maker as other window managers support dockapps too. I agree that they are unrelated in this level. They're just put together in a repo trying to lower administrative overhead but this does not make them related. But this is precisely the point! They become related once you do that, you can not have both at the same time. Either they have separate repos with separate maintainers deciding when to release new versions, or they are treated together like a whole. If you do that, it doesn't make sense to have them all in one repository in the first place and the difficulties pointed in this thread are related to trying to solve the wrong problem. And when you have the wrong problem to solve, no matter what you do it won't be the correct solution. Could there be a middle ground where we can have the advantages of both? Like keeping them in one repo but using separate version numbers and releasing them separately (either by tagging them separately or creating tarballs for release versions and putting them somewhere official)? I think this is what was proposed. What's your opinion on this? I'm sorry, but I cannot imagine what releasing them separately would even mean. There were patches to wmbiff recently. What should I do? Write a patch changing the #define version x.y for wmbiff only and announcing that I'm releasing a new wmbiff? What about the others? Take a look at the history of the repo and give me suggestions about which packages deserve a new version to be released and which version numbers should they have? Now take that list and let's write patches for their individual version numbers and let's generate tarballs for them and upload them somewhere. I don't think this is going to work, seriously. I cannot imagine me doing that. Now compare with my view. I tag the repo with some version number, and then that's the automatic release for all dockapps in there. If users have problems with one dockapp they can say, my wmbiff from dockapps.git version X does not work. And everybody will know exactly which version he's talking about. IMO apart from the driver analogy does not really apply here it also may require a bit bigger change in distros' workflow so it does not make things easier for everyone. I
dockapps.git repo redesign question
Hi, everyone! As Fedora packager, I find it difficult to work with current dockapps.git repo. There was discussion about that couple of months ago, let me remind key issues: 1. No releases for particular dockapps. Yes, we have continuous development, but package maintainers need release tarballs. 2. Dockapps uses different versioning schemes. There is no way to know version of a particular dockapp. I'd suggest to move from repo.or.cz to github. I have already registered dockapps organization at github. Each dockapp will have its' own repository with own history (I can do it) and tags. We will have all github social features, like forks, pull requests, issues and stuff. Github also provides tarball download features for all published tags that will satisfy package maintainer. What do you think? P.S. I can keep history for each dockapp from Strip off version numbers from dir name commit, or from the beginning of time. The later needs a bit more work... -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature
Re: dockapps.git repo redesign question
On Wed, 3 Apr 2013 at 15:06:36 +0400, Alexey I. Froloff wrote: Hi, everyone! As Fedora packager, I find it difficult to work with current dockapps.git repo. There was discussion about that couple of months ago, let me remind key issues: 1. No releases for particular dockapps. Yes, we have continuous development, but package maintainers need release tarballs. 2. Dockapps uses different versioning schemes. There is no way to know version of a particular dockapp. What about using a unified dockapp version for all dockapps under the repository? Say that I tag the repo now as 'version 0.5' and all dockapps will have the extra version 'dockapps v0.5' attached to them. I'd suggest to move from repo.or.cz to github. We will have all github social features, like forks, pull requests, issues and stuff. Github also provides tarball download features for all published tags that will satisfy package maintainer. I don't see that as really necessary. Apart from the pull request, which is not really needed for dockapp patches unless someone starts working with them as his/her dayjob and writing dozens of them, repo.or.cz has the other features too (which nobody uses anyway too). I have already registered dockapps organization at github. Each dockapp will have its' own repository with own history (I can do it) and tags. What do you think? Having one repository for each dockapp is way too much overhead, IMO. I won't have them all, for example. Simply because it's a pain to keep track of them all and do 'git pull's etc. And quite frankly, these unmantained dockapps which were ressurected in dockapps.git are so small that not having the fine version granularity for each of them makes sense. I say it's much more efficient to say I'm using wmbiff and wmpager from dockapps version 0.5 then saying wmbiff version x.y and wmpager version z.y and go to each repository and check things out individually. It's _way_ more efficient to have them under the same repository. P.S. I can keep history for each dockapp from Strip off version numbers from dir name commit, or from the beginning of time. The later needs a bit more work... Once one has more work to do, it is easier to fall behind and delay stuff and make others wait for it. When _I_ have to deal with inefficient work I run away screaming like mad. So my approach is to always make sure that the work to do is optimized as much possible so that I don't have to run. And IMHO you seem to want to create a more inefficient workflow around the already-not-loved-enough dockapps. My views might be wrong of course and more opinions are welcome. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On 03/04/2013 18:59, Alexey I. Froloff wrote: On Wed, Apr 03, 2013 at 06:03:09PM +0200, Rodolfo García Peñas (kix) wrote: I think that every dockapp should continue with their version number if the code doesn't change. I think dockapps repo is only to hold all applications together and avoid lost them. How do you suggest tracking dockapp versions? IMO, I should use the version number included in the code by the last person that make changes. If there are changes, but no new version, then using the old version number, +git-date where date is mmdd. perhaps the script used to do the nightly package for wmaker (at debian folder) can help you to create the .tgz files. You can create the .tgz for every dockapp, with a new version, only if the revision change. What is that revision you are talking about? I've changed the code of wmfoo dockapp and decided to release version 0.4.18. What's next? How do I tag this release and make a tarball? I don't know. Perhaps incluiding some file with the revision number. Next question: I want to make tarball for the newest version on wmbar dockapp. Just checked out the dockapps repo. How can I do that? If you are uploading the .tgz to any place, then the package is there. But, anyway. I think your idea is good (except I don't like github). If you (or you and Carlos, or you Carlos and X (where X is not me [sorry, but really, my time^H^H^H^H no time])) maintain the dockapps repo, perfect. I only try to say that every dockapp is different, because are different applications, and have different files and different file tree. Perhaps, we should work in other direction, like change things to make the dockapps with the same struct, include machine-readable files,... I don't know. I wrote in my notebook (paper): - Create an script to make dockapps tgz's and upload to any place. - Create a new dockapp library with the common code to do common (basic) things, like: * Code to read the CPU (used by wmmon, wmcpumon,...) * Code to read the network interfaces (speed,...) used by multiple dockapps too. Because I am not doing it, because I am with other things, feel free to do what you want. If you need help, and I can help you, I'm here. One thing more, please hold only *one* repo for the dockapps. Saludos, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Wed, 3 Apr 2013 at 20:40:02 +0200, Rodolfo García Peñas (kix) wrote: One thing more, please hold only *one* repo for the dockapps. If we can agree on that first, we can try to work out the rest. But I also feel like having a central place for all these dockapps is much better than having many scattered around. Another thing to consider is why does it matter to have a version for _each_ dockapp. The strongest reason I guess is to be able to refer to something specific when complaining about them, like in dockapp foobar version x.y.z is not working. If everybody agrees with that and all dockapps are inside the same repo, then it's also easy to tag the repo and refer to that. For example, I don't even know nor do I care about which version 'wmbiff' has right now. But I can say that it doesn't compile in the current dockapps.git repo today with a recent gnutls lib. The label to which I'm refering to is therefore the repo itself, not the dockapp. So my implicit suggestion to distros wanting to have the dockapps from dockapps.git is that they should package them in one package, not 41. Say you put every dockapp under dockapps-repo-version.rpm and be done with it. Would that work? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On Wed, 3 Apr 2013 at 21:30:50 +0200, Rodolfo García Peñas (kix) wrote: On 03/04/2013 21:25, Carlos R. Mafra wrote: On Wed, 3 Apr 2013 at 20:40:02 +0200, Rodolfo García Peñas (kix) wrote: One thing more, please hold only *one* repo for the dockapps. If we can agree on that first, we can try to work out the rest. But I also feel like having a central place for all these dockapps is much better than having many scattered around. Another thing to consider is why does it matter to have a version for _each_ dockapp. The strongest reason I guess is to be able to refer to something specific when complaining about them, like in dockapp foobar version x.y.z is not working. If everybody agrees with that and all dockapps are inside the same repo, then it's also easy to tag the repo and refer to that. For example, I don't even know nor do I care about which version 'wmbiff' has right now. But I can say that it doesn't compile in the current dockapps.git repo today with a recent gnutls lib. The label to which I'm refering to is therefore the repo itself, not the dockapp. So my implicit suggestion to distros wanting to have the dockapps from dockapps.git is that they should package them in one package, not 41. Say you put every dockapp under dockapps-repo-version.rpm and be done with it. Would that work? IMO, no. Probably I want have only some dockapps, not all. My point is that it doesn't matter to much. Say you want to use only wmpager. You install the dockapps package and you also get other 40 dockapps that you didn't want, but is that really important? They are so small! IIRC, KDE games which would install a bunch of them. I think that makes sense. The same for wmaker dockapps. Why not install all of them in one go? But this is not incompatible with your idea. All dockapps can have the same version and I can have one meta-package dockapps or wmaker-dockapps with different packages (one per dockapp), and build all together. The reason because I don't like have the same version is because every dockapp is different, from different developers,... but, perhaps now is time to join them. Some of them are at the dockapps repo because are unmaintained, missing,... so perhaps we can change the version. That's what I think makes more sense. We should think about the dockapps from dockapps.git as a whole. Being too fine-grained will hurt because that's mantainance overhead. One repo to rule them all. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
