> > Also as a (potentially) related statement. 9front has taken a policy of no > computer generated code > for any contributions going forward, this includes generative AI or large > language models of course.
I assume that's defined not to include (say) mpc, yacc, sed scripts, etc! On Sun, 10 May 2026 at 18:34, Jacob Moody <[email protected]> wrote: > On 5/9/26 07:31, Lucio De Re wrote: > > > > On 2026/05/09 06:03, [email protected] wrote: > >> 9front and 4e/9Legacy are separate, independent communities with no > >> obligation to support each other, but it’s always encouraging to see > >> someone willing to help both. Yaroslav, thank you for your efforts. > > > > Let me add my own gratitude. > > > > I think this is a great approach and I have been considering the > > approach myself, I just don't happen to have the skills and persistence > > to accomplish as much as Yaroslav did. > > > > As for those who now seem to want to preserve the "purity" of 9front, > > let me say that I entirely understand where you come from, specially > > from the perspective of supporting what necessarily resemble > > regressions. On the other hand, it is equally unfair to suggest that > > those of us that appreciate both the spirit of legacy and the pragmatism > > of 9front (and the now dated pragmatism of legacy and the modern spirit > > of 9front) should not be encouraged to pursue yet another development > > direction. To me, personally, convergence toward the best from all > > sources is well worth the price, as Yaroslav suggests, of needing > > frequent (ideally not frequent, but even then...) rebasing. > > No one here is discouraging alternative paths, if anything I encourage > folks > to do this work if they want to maintain git9 for other systems. These > paths > can be explored entirely without involvement of 9front, in fact I'd say > we're there already, the fact that you can pull in git9 on 9legacy with > this diff is proof of that. > > What is being asked for here is not some permission for this alternative > path however, what is being asked is for 9front to take on the maintenance > burden of there being multiple paths. These are two disjoint things. > > When you are asking someone (or a group of people) to make their lives more > difficult/inconvenient (like using 30 year old GNU utils or ifs= footguns) > in order to make your life easier (keeping the git9 9legacy diff smaller) > you > are asking us to do a favor for you. > > This is why my whole comment at the start was that this PR felt > inconsiderate/rude to me. > Am I incorrect in seeing the dynamic like this? It's possible, I am just > trying to convey how > things come across to me. For 9front, git is our update mechanism, if it > breaks we're in some > pretty annoying trouble. > > As Dan and Charles pointed out, this is a bit further bothersome because > there was not even > really any initial thought in to "which of these 9front improvements can > we take back to 9legacy". > Or at least have a discussion about which of these changes are for the > better and which are perhaps > not super necessary. > > Also as a (potentially) related statement. 9front has taken a policy of no > computer generated code > for any contributions going forward, this includes generative AI or large > language models of course. > > - moody ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td167d7e8cebadcc4-Md973091f20d2a341255c4d6b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
