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 [email protected].
