I'm not entirely convinced that this is what is best for the project, even though it was my suggestion. I think it solves a lot of difficult issues about how to run the project, but it also splits the developers and possibly the users. On the other hand, it would let the two different development philosophies present in the group each reach their own potential, so would be very interesting in that respect.
On Mon, Jun 27, 2022 at 11:35 AM Nico Huber <nic...@gmx.de> wrote: > ... All the documentation in the world about flashrom would > have to make exceptions, e.g. "if you use legacy flashrom, you need to > do this instead...". That alone seems much more effort than keeping > a few lines of code around. > Currently existing documentation would reflect the legacy flashrom. Upcoming documentation could reference either, but should probably specify which it's referencing. I don't see a big issue. > The key motivation for two branches would be to allow flashrom as a project > > in terms of core logic (driver API / remove global state / etc) to > progress > > forwards with well supported (tested) hardware that we can maintain. That > > means, essentially, removing the fear of breaking exceptional old > hardware > > drivers that the majority of active contributors do not have the means to > > test with practically speaking. > > It's all open source, you know. There is a simple way to test any patch: > reading and reasoning. You make me believe that people are actually > afraid to read and understand the existing code that could break. > I don't think reading and reasoning actually qualifies as testing. While I agree that it's obviously good, it's just not the same as testing. Classic flashrom could be maintained this way if desired, but Modern flashrom should (in my opinion) be tested on actual hardware to verify that everything is working. This also gives an easy way of what should be kept in modern vs being removed. The preferred method for deciding what to keep would be based on whether or not there's hardware easily available for testing. If there is, we keep it. If we can't find hardware to test something, we remove it from modern, and let it be maintained in the classic branch as desired. My thinking is also that each branch would also have different people in charge of making decisions about the branch and how it's run. This would allow for a significantly different development pace between the two branches. For example, one branch could have quarterly or biannual scheduled releases, while the other branch releases only when its developers feel it's ready to be released. Another question is how we'd want to request that package managers handle this. We'd want to make it clear that this is a philosophical split, and that they should make their own choice, or even include both flashrom versions. Martin
_______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
