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 agree that it might not be the easiest solution for distros right now because they want to have different packages for them. But let's face reality. There's no one maintaining these dockapps in the usual way (say like Alexey himself is maintaining wmvolman). So there won't be anyone deciding when to release a new version of wmbiff, or having plans for doing that. We are just trying to have them compiling and working, and when something breaks we hopefully fix the ones we care most. The purpose of the dockapps.git is to have a place to send these patches. > 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 does not work well, I think. Let's say today I tag the dockapps.git repo as wmbiff-2.0, how would that help someone? -- To unsubscribe, send mail to [email protected].
