In our previous episode, Lukasz Sokol said: > > I don't think this needs to be done formally. Any users can package > > snapshots cq pseudo releases and mark them as test, and release them for > > feedback. Then process the feedback, triage it, and communicate that back > > upstream. > > Which sometimes takes so long, that the downstream tester bypasses the distro > maintainers and submits patches directly upstream... > ... only to find out that his patches are not going to be present in /this/ > incarnation of the distro release and he'll be lucky if they actually hit > the next one.
True. This happens with FPC too, if some feature is postponed to the next major version that can be a long time. But that some projects take even more time doesn't mean the principle is flawed. > > That's how the really big projects (like distros) work too. Similarly with > > the various branches of the Linux kernel, where there are often third party > > builders that track a certain target. > > Linux approach changed around 2.6.12 somewhere (or later) with/after the > upcome of git... > now they have 6-9 rc releases, merging new features AND bugfixes, one per > week or 1.5 average, > then branch the head off and the stable branch is strongly advised to be sent > bugfixes /only/. And they have a staging branch before that. I meant with the example that the stable, head and staging groups are managed by different people and teams. > (Truth be said, I /do/ see resemblance of LK to FPC approach, only FPC has a > slower > pace and uses different numbering scheme, (which can be (mildly) confusing > when > one switches contexts often;) also you call it feature-freeze, they call it > stable branch... > but it's the same idea in its essence) Linux is big business. FPC not. The core point of the analogy is that not every detail of all work within a project needs to go through /one/ central point. (like the FPC core team in our case or Ueberpenguin Linus in the Linux kernel) > > So the question should be, when do you think you can release your first > > pseudo stable snapshot? Throwing it all back to core is useless, since that > > increasing tasks will only slow development more. > > I for one think, that just encouraging /anybody/ to release pseudo-stable > snapshots, > is not going to help, rather end up with some of them being forks, > fragmenting the ecosystem... > (remember the times of linux 2.4.x-ac or -mm versions?) They served a purpose, even if the purpose is no longer needed later. Moreover it has no point to compare with an ideal scenario (new version of fpc every quarter major branch per year or so) that is never going to happen. What FPC needs is longterm committed people on both development and maintenance topics. > You might end up with some people that are less patient instantiating their > own git repos, > and adopting faster pace, and the main repos becoming outdated... because > their downstream > patches won't apply to upstream without considerable amount of work. That simply can't be stopped. It is of course annoying since usually the support burden for such projects still falls on the original project (even if only 2nd line). But anyone can suddenly imagine he can do a better job and start an independent branch, I don't think it is wise to let that fact influence how to setup the process too much. > I'm actually with Silvio on this Silvio sets goals but doesn't provide the resources to do so. That is the crucial flaw in such rants. > (maybe by altering the criteria, of how much of a change is considered fit > for a next major release, > /considerably/ down; > even if it means, if tracking the features of Delphi compiler is any factor, > that for 1 Delphi release, FPC releases 5 or 6 major releases before it > catches up) That is another fundamental flaw, trying to plan something in a project that survives on voluntarily work of volunteers. There is nothing that CAN be steered top down in projects like this. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
