On Thu, Oct 27, 2016 at 12:30:08AM +0100, Dominik Vogt wrote: > From the point of view of the users and the people reading > fvwm-workers I am very sceptical. We have already abandoned cvs > in favour of git, and as you can see, this has even further > reduced the number of old timers who have set up a development > environment. I'd be very careful about sending yet another "we > don't want to have anything to do with the old stuff" message to > the world.
In the last two years, the only people I've seen contribute to fvwm have been Dan Espen, myself, and you. Going back five years, the only people who've actively contributed to fvwm have been (again): Dan Espen, myself, and you. It was only _very_ recently that I actually bothered to make things easier on myself and move fvwm over to using git---and that wasn't a personal preference point, it was the fact that Jason was getting fed up of maintaining the CVS server; it kept breaking. It was the right decision for the project---and putting it on somewhere such as Github should raise its awareness. It's where a lot of people will go to find software, and from looking at fvwmorg/fvwm on GH, I note there's 60 people currently watching the state of how development is progressing. That's a good thing. Plus, it might open up the likelihood for additional patches. Has moving to git therefore stifled those people who were working on fvwm at the point I moved it? No. Has there been people prior to moving to GH with previous commit access to CVS who've asked me for commit rights to GH? No. That's because there are only two (at best) three people who've really been keeping fvwm going for a long, long time. None of this has reduced the number of old timers. They're just not here anymore. If they return (presumably with a crochet blanket over their knees and a nice hot mug of tea) they'll be welcomed with open arms. > Switching to new infrastructure, we'll automatically lose some of > the people that are interested in fvwm development, be it that > they miss that the mailing lists have moved or that they won't > understand why there are two projects with the same name and which > to look at. On the other hand: So no where have I ever suggested moving things like mailing lists around, nor have I mentioned about needing a new website. That's not true either, and it would be a rather odd thing to think otherwise. That _would_ be harmful. > * Staying on the same mailing list: Readers will notice over time > that we're working on something new, that version 3 will be a > more modern and radically different thing than version 2. They > may become interested in it or not, only time will tell. There > is no information hurdle they have to take to find out that > something new is being done. Correct, and something I support. > Bugs reported for fvwm-2.x will still be relevant to fvwm-3.x > for a long time (depends on the bugs). We don't want to keep > people from reporting bugs on the list because they might think > the project is dead when it has just moved. In the past year, there's been a handful of bugs reported that has really impacted fvwm2 to the extent where, were there a fvwm3, that work would be backported. What you're assuming is that the image---were there to be fvwm3---is that we somehow don't care about fvwm2. That's not true either. What I've been keen to stress all along with fvwm3 is that it's a chance to correct a number of things with fvwm2 that are so costly it would either break those things some users are keen to keep, or trying to make improvements means the cost of backwards-compatibility is high. In creating fvwm3, that's where I would personally spend most of my development time, because fvwm2 would either be left in maintenance mode (let's be honest here, that's all it has been in for some years now), or others could decide to add a few things here and there. It's analogous to fvwm1 -> fvwm2, I suppose. There's plenty of people who still prefer fvwm1, that's their _choice_ though, since they know about newer/other versions. > * Switching git repository: Given that the current amount of > work going into version 2.x is very low, having both versions > in the same repository is certainly manageable. It's just more > work for anybody who is interested in both repos (and getting > access to github *is* very cumbersome compared to cvs access in > the past). Access to github is cumbersome compared to CVS? That's not true. Maybe you dislike something about it, or misunderstand something about it? I don't know -- but when you consider the number of projects on GH, the number of users signed up to it, the number of personal projects, and the number of drive-by patches projects receive (including my own projects which still surprises even me), you have to wrong in that assumption, Dominik. Now, as it happens, separating out the repository (and I'm not going to repeat myself again as to why I think that's a good idea; see previous mail), the other point is that it allows us to group who can commit to which repo---and possibly allow teams of people to manage either or both. I rather like that idea. > * Switching to a new web space: This would make us the target of > ridicule for years and cause musch confusion. How would we > explain that there are two distict web pages for the same project You wouldn't. You can have different information on the same web space. > * With new infrastructure we'd run the risk that fvwm is kicked > out of even more distributions. "even more" implies you've evidence to suggest that practise is current and happening. I've not seen this. New infrastructure it just that---infrastructure, and doesn't provide a barrier to anything at all, least of all whether a Linux distribution chooses to ship fvwm or not. There's only one thing to look for right now. Oh, and by the way, I've had emails thanking me for moving fvwm to GH since it makes their packaging/monitoring, etc., a doddle. But that's an aside. > So, is there maybe *another* way to foster enthusiasm about a new, > incompatible version? Maybe we just need to do some "public > relations" work here. A while ago you started a discussion about You're assuming something trivial about code management is going to have this huge impact, when it won't do, Dominik. It's just a question of management and how users are informed about what's happening, why, and what it means for them. If anything they gain a lot more, and should they really care, we might even get suggestions on fvwm3 from existing users. > a new logo contest. Great idea, why not make it an event around > the official "fork" date. I'd be happy to donate another prize. Sure; what prize did you offer last time round? > We'd have something "new" practically from day one. Maybe an Irc > "fvwm version 3" kickoff party where we explain our plans for the > future? When did you last appear on #fvwm on freenode? You and others are always welcome (it's not an invite-only club, but you know what I mean) --- it would certainly allow other developers to give their viewpoints to users. Right now, it's just me. > > It's not as if we're backporting features or fixes between the two. > > Of course I'll continue backporting fixes like the recent ones in > event handling in the window management core. This code is > changes at a very low pace, and backports are easily done. For now they might be --- but with the parser changes, etc., these backports are going to become harder and less relevant. That's the point of having a separate repository for these things---it reinforces the inevitable separation of fvwm2 to fvwm3. That's not a swan song, or a proverbial middle finger to those users who are choosing to stick with fvwm2, it's about managing the expectations of what fvwm3 is about, and where that will inevitably leave fvwm2 over time. fvwm3 (if it ever even starts), will be very different at the code level -- it's no different to fvwm1 versus fvwm2. Do we backport changes from fvwm2 to fvwm1? No. > Not at all, that would just greatly complicate things and confuse > people. What use would two copies of the same code in deifferent > repositories be? See above. Backporting is easy between repositories---if that's a conversation we need to have (including the git commands needed) then let's have that, and I'll prove to you and others that it works. But the _need_ to do that, Dominik, although perhaps more likely to begin with, will become less-and-less, and backporting from fvwm3 -> fvwm2 will be harder as structs and parsers change, etc. That problem is true whether fvwm3 were to be in the same repository as fvwm2 or not. So the physical separation is just that. "Copying" was a bad choice of words. With fvwm3, what I would suggest is taking the current fvwm2 repository (including all of its branches) and making that the basis for fvwm3. That way, we can change it however we like. We're then able to link fvwm2's repo in to easily backport changes using standard git commands, etc. It's something I'd be happy to run through if that's required, or wanted. Kindly, Thomas
