Thanks Adam, Rob. Adam, option #3 does seem like it would be the cleanest way to go. I wouldn't mind doing the work, if it's OK with you guys if we move forward with this idea. The repository would be "offline" for a few minutes while the switchover is done, but it shouldn't be a big deal. I think maybe we just need to confirm which branches should be kept. The default, pyglet-1.x-maintenance, etc. Are there any branches besides the maintenance branches that are needed?
Rob, agreed on the experimental folder. -Ben On Monday, September 26, 2016 at 3:35:51 PM UTC+9, Rob wrote: > > Hi, > > Indeed the repo might need some cleaning. I was also considering that. I > just could not find time to do that. > To mee it also seems that most of the experimental stuff can go. And > contrib should be fixed. Also quite some old branches should be pruned. > > Rob > > On 25 September 2016 at 22:22, Adam Bark <[email protected] <javascript:> > > wrote: > >> On 25/09/16 16:24, Benjamin Moran wrote: >> >>> Hi guys, >>> >>> I've been looking over the repository, and it really could use a >>> cleanup. There is a lot of stale, or broken code around. In particular, >>> the "experimental" and "contrib" directories. >>> >>> For "experimental", most of the code is broken at this point. Some of it >>> has actually already made it's way into the main codebase, and other things >>> no longer work properly with the current master branch. It looks like most >>> of this code can be removed (especially the bits that are already in pyglet >>> proper). If there are still any interesting ideas in there, they can be >>> kept for further discussion. >>> >>> For "contrib", most of the code would need to be updated to Python2/3 >>> dual compatibility at the least. The individual modules need a review to >>> see if they are still working, and either fixed up or removed if not. >>> >>> Finally, there are a lot of old branches still in the main repository, >>> most of which have not seen any activity for many years. It's probably a >>> good idea to prune out any dead branches. >>> >>> Any thoughts on this? I think a lot of the cruft was accumulated because >>> of the intial move to Bitbucket, and then the update to Python 2/3 dual >>> compatibility. Development has continued, but It looks like nobody wanted >>> to hastily delete the old stuff. I think it's pretty safe to do so at this >>> point now. >>> >>> https://www.mercurial-scm.org/wiki/PruningDeadBranches >> I think it might be because it can be difficult to get rid of branches >> once they're public. They could be closed but it will add a load of commits >> that just close these old branches. The third option is probably the best >> one if someone is willing to go through that. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pyglet-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/pyglet-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
