On Mon, 2020-11-23 at 12:53 +0100, Michael Osipov wrote: > Am 2020-11-22 um 23:09 schrieb Oleg Kalnichevski: > > On Sun, 2020-11-22 at 20:44 +0100, Michael Osipov wrote: > > > Am 2020-11-22 um 20:16 schrieb Oleg Kalnichevski: > > > > On Sun, 2020-11-22 at 20:11 +0100, Oleg Kalnichevski wrote: > > > > > On Sun, 2020-11-22 at 20:04 +0100, Michael Osipov wrote: > > > > > > > > > > ... > > > > > > > > > > > > Wait a second. I am not sure what release vote you are > > > > > > > referring > > > > > > > to. > > > > > > > Web site publishing is not subject to any kind of vote. > > > > > > > > > > > > I was not talking about website vote, but about a release > > > > > > vote, > > > > > > e.g., > > > > > > core 4/5, client 4/5. Along with that staged release there > > > > > > goes > > > > > > a > > > > > > staged > > > > > > site. See this vote: > > > > > > http://mail-archives.apache.org/mod_mbox/maven-dev/202011.mbox/%3C6d098deb-00ab-ec01-1c0f-73748462d521%40apache.org%3E > > > > > > > > > > > > When the vote passes for the release, you complete the > > > > > > staged > > > > > > release > > > > > > as > > > > > > well as promote the staged site. > > > > > > > > > > > > Is that better? > > > > > > > > > > > > > > > > I am not sure. Web site publishing should not be related to > > > > > any > > > > > vote > > > > > at > > > > > all. I should be able to take any officially released > > > > > artifact > > > > > and > > > > > republish its content at any point of time, add more content > > > > > or > > > > > fix > > > > > things. That should never require a new release of any sort. > > > > > > > > > > > > > In other words one should be able to contribute new content to > > > > an > > > > already released component, say, a performance optimization > > > > guide, > > > > submit a PR against the web site project and a committer should > > > > be > > > > able > > > > to review the PR, hit merge and get the damn thing published > > > > immediately. > > > > > > Let's split site and components logically. > > > > > > site: Every change in master will go almost immediately online > > > right > > > now > > > since we have a Jenkins job right now. Try it out and you'll see. > > > components: They are considered to be published with a release > > > cadence, > > > but the steps I have described can be performed at anytime from > > > master > > > or branch w/o any release. What you have to bear in mind that > > > currently > > > neither core nor client have any handwritten content and since > > > the > > > top > > > bar contains the current version from a user's POV, this will be > > > weird > > > because it will tell 5.1-beta2-SNAPSHOT and if code has changed > > > you > > > will > > > inadvertly publish updated Javadoc which will even more cause > > > confusion. > > > I wouldn't do that. If really necessary I would recomment to > > > switch > > > to > > > the tag apply the changes locally and publish the site, but this > > > stil > > > would be ugly because user's wouldn't see this content in the Git > > > repo > > > associated with this tag. We at Maven avoid such situations. > > > > > > My advise is to bundle documentation when it is tightly coupled > > > to > > > it > > > from release to release with a component otherwise this should > > > live > > > in > > > httpcomponents-website. > > > > > > For instance, at Maven we have guides [1] on the website, not in > > > the > > > components. > > > > > > Does it clear up the situation? > > > > > > > As long as project specific hand-written content stays > > in httpcomponents-website (like it is now) and individual projects > > only > > contribute release specific reports (javadocs, etc) I am fine with > > that. I might be mistaken but I thought it was proposed to move > > project > > specific hand-written content to the project repositories. That > > would > > be a big step back in my opinion. > > It is problematic to have the same subtree twice. It will simply not > work. I would at least move the index.apt to the subproject and > consolidate the rest in guides or examples of of the component trees. > The content you have mentioned does not change that often which > requires > an out of release modification. If that is really necessary you can > still generate the site and just manually commit that specific HTML > file. We at Maven do get report on incorrect component > documentation, > but this is always addressed with releases. No one ever complained > that > this hasn't been published immediately. > I will pick up Hervé's proposal of content and components subdirs > and > will restructure. This will leave the current entire site intact and > we > can evaluate, decide and complete the new approach. > > Is that acceptable? >
So, we would go back to the days when fixing a typo in the logging guide required a new release and a release vote? I remember those days with great "fondness". Do we have to move hand-written content back to projects that require a release vote simply to work around some limitations of the maven site plugin? In this case I would rather lose reports that individual projects contribute to the web site. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
